<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace">My responses:<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 27, 2013 at 10:14 AM, Tzafrir Cohen <span dir="ltr"><<a href="mailto:tzafrir.cohen@xorcom.com" target="_blank">tzafrir.cohen@xorcom.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Nov 26, 2013 at 10:04:58PM -0700, Steve Murphy wrote:<br>
> Hello--<br>
><br>
> Boy, it's been a long time since I posted to the dev mailing list!<br>
><br>
> I'd like to announce a proposal to the Asterisk Community, that I<br>
> introduced at Astridevcon last month. It is a new API for playing sound<br>
> files (mainly speech). A pdf describing the Proposal in some detail is at:<br>
><br>
> <a href="http://www.gmvoices.com/downloads/steve/sayscripts.pdf" target="_blank">http://www.gmvoices.com/downloads/steve/sayscripts.pdf</a><br>
<br>
</div>My initial reaction to this is that it is a reimplementation of<br>
text-to-speech.<br></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">It will make Asterisk capable of using larger sound file sets,<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">
sounding more natural than even text to speech. <br><br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">Someday text to speech packages (Ivona, for example, which are plain AWESOME), will<br>
</div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">be indistinguishable from natural speech. But they haven't quite<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">
reached that status yet. Until they do, better quality sound sets<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">will be possible in Asterisk. Not only for special IVR's, but for<br>
</div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">Asterisk itself.<br><br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">But, that being said, this is far from being its sole purpose. Right<br>
now, translations are very difficult to generate, within Asterisk, <br>and via IVR's. The SaySentence stuff will make all this much easier.<br><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It also removes some existing functionality (saying a date and such).<br></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">Absolutely false! All the date pronouncing capabilities presented<br>
</div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">by the Say stuff is all covered in the SaySentence spec. Check it out.<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">
It may even cover all this better than the assembled existing say stuff.<br></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The proposal also ignores say.conf . When talking with Steve at the<br>
DevConf I made the mistake of assuming that as say.conf is only<br>
referenced in app_playback, it is only used by Playback(), which is not<br>
the case.<br></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">Wrong again. I didn't IGNORE it. This proposal replaces it. I built<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">
the whole spec around what already exists in the various "say" stuff.<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">If I missed anything, let me know. As far as I know, I added some cool<br>
stuff to the mix, like special combinations that have a different<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">pronunciation than just the concatenation of the individual pieces, for example...<br>
</div><div class="gmail_default" style="font-family:courier new,monospace;display:inline"></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Languages in say.conf:<br>
<br>
$ grep '^\[' configs/say.conf.sample<br>
[general]<br>
[digit-base](!) ; base rule for digit strings<br>
[date-base](!) ; base rules for dates and times<br>
[en-base](!)<br>
[en_GB](date-base,digit-base,en-base)<br>
[it](digit-base,date-base)<br>
[en](en-base,date-base,digit-base)<br>
[de](date-base,digit-base)<br>
[hu](digit-base,date-base)<br>
[fr](date-base,digit-base)<br>
[es](date-base,digit-base)<br>
[da](date-base,digit-base)<br>
<br>
Why isn't it more commonly used?<br></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">Personally, after reviewing all the stuff in the say.conf package,<br></div>
<div class="gmail_default" style="font-family:courier new,monospace;display:inline">my first guess is that it is not very well documented, nor advertised.<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">
It is not used in the Asterisk core, and does not help you with stuff<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">hard wired into the Asterisk source.<br><br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">
Not only that, it is still oriented around the "group by phrase" concept,<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">instead of "group by full sentence". In the end, while this stuff might<br>
</div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">help with localizing some of the substructure, it isn't tied directly to<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">
full sentences. How can you translate anything properly without knowing<br>the full context? Most of the complexity introduced with gender/topic variations<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">
in rendering dates, numbers, etc, and codified in C all fall away when you<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">step back and pronounce sentences in a single unit. The basics *are* all in <br>
</div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">the Say and say.conf related stuff, but it lacks the unifying concepts. It is<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">
not algorithmic, and still depends on the C coded source in say.c, which to add<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">to Asterisk, means months of work and waiting as new releases roll out. Soundpacks,<br>
on the other hand, completely encapsulate a new language. No code submissions to <br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">Asterisk. Just put the sound pack together, debug, and publish. If all goes well,<br>
</div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">you may be able to publish sound sets not only for Asterisk, but other phone systems<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">
as well, using the same methodology. But, that's for the future.<br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline"></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
(On a personal note: writing the language support is a nice janitorial<br>
task for a native speaker of the language with a moderate level of C, as<br>
it easy to test and has no inherent concurrency issues)<br></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">The same applies to the SaySentence. Personally, I think the whole say.c<br>
</div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">methodology is a sinking ship. It's good stuff, don't misunderstand me, <br></div><div class="gmail_default" style="font-family:courier new,monospace;display:inline">
but needed a new base, a new philosophy, and some reorganization.<br></div><br><div class="gmail_default" style="font-family:courier new,monospace">And, yes, there is a lot of locale-specific stuff to glean from the various<br>
</div><div class="gmail_default" style="font-family:courier new,monospace">language specific routines now in Asterisk (See say.c, app_voicemail.c, etc).<br></div><div class="gmail_default" style="font-family:courier new,monospace">
It is a bit of work to do that, and even at that, a bit buggy on top of that.<br></div><div class="gmail_default" style="font-family:courier new,monospace">Whether to throw it away and start from scratch, or to glean, is up to those<br>
</div><div class="gmail_default" style="font-family:courier new,monospace">willing to work on these issues. I can do some, but I will need help.</div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Tzafrir Cohen</font></span><br></blockquote></div>-- <br><div dir="ltr"><br>Steve Murphy<br>ParseTree Corporation<br>✉ <a href="mailto:murf@parsetree.com" target="_blank">murf<div class="gmail_default" style="font-family:courier new,monospace;display:inline">
at </div>parsetree<div class="gmail_default" style="font-family:courier new,monospace;display:inline"> dot </div>com</a><br>☎ 307-899-5535<br><br><br></div>
</div></div>