[Accessibility] Multimedia framework requirements

Hynek Hanke hanke at brailcom.org
Sun Mar 20 06:50:40 PST 2005


On Sat, Mar 05, 2005 at 01:20:13PM +0000, Gary Cramblitt wrote:
> > 2 Audio requirements
> You may want to think about supported audio formats.  Most existing synths 
> seem to produce .wav files (Microsoft riff) or .au.

It's important that at least one widely used copressed audio format is
supported. The reason is the following one: The TTS system or the higher level
TTS server (like kttsd, gnome-speech or Speech Dispatcher) can include sounds
other than speech into the audio flow, e.g. to represent some kinds of events,
to precede capital letters in the text or to represent parenthesis and other
punctuation marks. It's highly desirable that these are user-configurable and
the user should have the option to use a compressed format for these soundfiles
(it's important for the distribution of such data etc.). On the other side,
there is no reason why the TTS or the higher level TTS server should care about
the particular data format the user wants to use (in other words, any format
supported by the audio framework should be allowed).

I'm going to include ogg support into the detailed requirements document.

> Also, there's the issue of how to deliver the audio to the audio framework.  
> Streams could be more efficient than files?  The TTS API discussion has this 
> as an unresolved item.


I appreciate you brang up that point, but I think this is outside scope for
this discussion since we are not writing and Audio API specifications but an
``accessibility requirements on audio frameworks'' document. I think all the
means of delivering audio used in today's frameworks are good as long as they
conform to the other more general requirements, specifically the one about
real-time responsiveness, the one about supporting multiple formats and the one
about reasonably simple use. The exact means how to ensure it should be left
to the implementators. This is of course different in the TTS API discussion
since it's goal is devising an API.

With Regards,
Hynek Hanke


More information about the Accessibility mailing list