[asterisk-dev] SaySentence/SoundPack Proposal

Thu Nov 28 23:03:47 CST 2013

On Thu, Nov 28, 2013 at 1:58 PM, Tzafrir Cohen <tzafrir.cohen at xorcom.com>wrote:

> On Tue, Nov 26, 2013 at 10:04:58PM -0700, Steve Murphy wrote:
> > Hello--
> >
> > Boy, it's been a long time since I posted to the dev mailing list!
> >
> > I'd like to announce a proposal to the Asterisk Community, that I
> > introduced at Astridevcon last month. It is a new API for playing sound
> > files (mainly speech). A pdf describing the Proposal in some detail is
> at:
> >
> > http://www.gmvoices.com/downloads/steve/sayscripts.pdf
>
> First example:
>
> * ret = ast_say_sentence(chan, “#*”, "<you_transferred> %m
> <to_your_account> %[o]d", balance, transaction_date);
>
> %m should be "money". At what currentcy? When I say this in French
> should I still say Dollars, or should it be Euros? And what currency
> for Spanish?
> Furthermore, you require the currency to be mmm.nn (exactly two 'cents'
> digits). Some currentcies (e.g. the Yen) have no 'cent'. I believe that
> some have a 'mil' (but I can't think of any off the top of my head.
>
> Here's the global view. You set your locale string for the LANGUAGE
variable on the channel. In the default case, the language is set up to be
"en" by default. If you are set up to use the SaySentence stuff, your
sayscripts are in /var/lib/asterisk/language/en. Now, I suppose, to be more
technically correct, there should be en_US, and en_GB, or any of the other
locales for english speakers. Right now, the en sayscript is pretty much
en_US. Thus, the dollars and cents, and the expectation that the money
value end with .xx. At some point, we'll put together the en_GB sayscripts,
and they will be pounds or Euros or whatever, and do the right thing for
the Brits.

But, if the channel is set up for de or fr or es, or any other language,
the code will search for that file and use its sayscripts, which might
pronounce Euros, or Yen, or rubles, or whatever, and might not expect any
.xx at the end.

Now, there are a lot of countries that speak Spanish. Each has its own
currency. But the ability to say the right currency in the right way,
should all be in the SayScript for that locale, whether it be es_ES, es_MX,
or whatever.

> The currency seems to me a rather local decision and should not be part
> of the code or of the language pack.
>

Tzafrir, as far as I know, the locale files are THE place to put such
locale specific information.
This is no departure from the system of organization presented by GNU
gettext, and is in use for
hundreds of languages in even more locales. The language pack is exactly
tailored for a specific locale.

>
>
> From what I understand, the sound set should include "you transferred"
> and "to your account".
>
>
Agreed.

>
>
> Anyway, you'll now need to go and fix each and every sound set for
> Asterisk. This includes each and every sound set in a supported language
> (such and English and Spanish).
>

No, my plan is to just convert the code in say.c to SayScript, and have it
use the same sounds
in the same way, for each locale, even if it isn't correct. But that's up
to the guys making those sound packs. Let's face it, not all the languages
provide overrides for all the sounds, and not all are completely correct.
If (for example), the folks doing the Greek translation spot an error, or
an ommission, they are free to add, or correct sound files at their
discretion.

>
> The really funny thing would be to have buggy sound sets. But why would
> you rely on code that is included with something that should only
> include data? For instance, REASTART at the right place could induce an
> endless loop, right?
>

I honestly don't understand your reasoning here, as to "that should only
include data". The reason why, is because I don't see the current Asterisk
code and sound sets being completely independent of each other. They are
not. The code calls out those files to play, and without the code, no sound
files would be played at all. Those algorithms, in the Asterisk source
code, are an integral part of the game. If you expect sound packs to only
contain sound files, you are ignoring that thousands of lines of code are
devoted to each language, and is smeared out in various places in the
Asterisk code base.
Last I counted, say.c has like 8000 lines of locale-specific code. There is
a great deal of language-specific code in app_voicemail. There SHOULD be
more language specific code in other places, especially where whole
sentences containing variables. (Maybe app_voicemail is the only
app/res/whatever to speak "complex" sentences, I haven't studied for that).

All I know is, that the current situation is insane. There are a LOT of
languages out there. And while Asterisk has really only a small number
coded, and recorded. To introduce a new language, you need to write a bunch
of code. It needs to be compiled into Asterisk. It has to go into trunk,
and it could be months or a year before it appears in a release. This is an
extremely slow and expensive process. Yes, I remember from long ago, that
the community is willing to "streamline" this, but really, look at the
history. In the last two years, I have seen very little in new language
introduction, even though there is no lack of possible languages to make
available.

As to the ability of a sayscript to infinitely loop, yes, at the current
moment, it can. But I promise that long before this code goes "production",
if it ever does, I will modify the interpreter so that if state does not
change in some number of loops, it will force termination with an error.
This is a fairly simple change to make.

Can you think of other problems that I might want to watch out for?

As to the possible poor quality of the results of a sound pack, well, it
applies to all the current sounds in Asterisk: report the problems, or
submit fixes, and someone will hopefully refine their sound pack.

If they don't, don't use them. Make your own. Or whatever.

If I were to publish submitted soundpacks for general distribution, I might
consider writing scripts for basic acceptance. I might require that they
parse without error, and contain the all sound files referenced by the
SayScripts. I might require some certification that the sound files follow
the scripts, and who know what else, to insure some level of quality and
sanity. But in the end, it is "buyer beware" sort of situation. End users
should test them out before putting them in production.

murf

-- 

Steve Murphy
ParseTree Corporation
57 Lane 17
Cody, WY 82414
✉  murf
 at 
parsetree
 dott 
com <murf at parsetree.com>
☎ 307-899-5535
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131128/60234825/attachment-0001.html>