Re: GNOME 2 Sound Architecture and APIs?

[Bill Haneman <Bill Haneman Sun COM>]

>I guess sound events are just an optimization to quickly send music
>out (at a fundamental level, I do not think there is any difference
>between telling esound `play clip #3' than playing it ourselves).
>
>Is this functionality even important to have?
>
>Miguel.

The big issue for accessibility, at least, is latency.  Presumably the 
sound event framework allows sounds to be played on a near-real-time 
basis, provided they have been pre-loaded.

I'm not sure if this helps or hurts text-to-speech, since usually text 
to speech sends the clip at the same time as the request to play it. 
Rather than scheduling it to be played at a certain time, the client 
wants it played "ASAP".

I have been told that latencies of around 50 ms are the target for 
text-to-speech, blind users navigate spoken user interfaces very, very 
rapidly (using speeded-up voices, up to 5 times normal speaking rate).  
As important that startup latency is the ability to stop the emission of 
a sound.

While I'm on the topic ;-)

text-to-speech will require of the sound subsystem:

latency <= 100 ms
ability to stop sound emission
ability to readily mix sound requests to play concurrently

voice recognition will require sound acquisition but probably
latency requirements are less stringent.

If we get all that I will be delighted :-)

regards,

Bill
------
Bill Haneman x19279
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland