[Accessibility] TTS API interface description + reqs update
Hynek Hanke
hanke at brailcom.org
Mon May 1 05:40:13 PDT 2006
Gary Cramblitt writes:
> 2.5. The defer() method implies a heap of "paused" messages. I'm wondering
> if that is really necessary.
The defer() method is not mandatory. I agree with the suggestion bellow.
> Is there an upper limit on the number of
> messages in the heap? To ease the burden on implementors, I suggest changing
> bool_t can_defer_message;
> to
> int can_defer_message;
> 2.7. AFAIK, all existing speech synthesizers produce raw pcm or wav audio.
> Rather than deal with the complexity of other formats (ogg, flac, etc.), I
> suggest that we limit the api to these two formats. Furthermore, only
> uncompressed wav files.
We have previously decided not to handle audio in this API, so the
only way to meet the decision is not to impose any limits on audio
formats. Limits on audio formats possible to use were originally thought
of as implementation detail (one that would eventually not be handled
by us but some multimedia API provided by the system).
Of course the decision of not imposing limits on audio can be changed.
My concern is that in the future someone could come with a useful
synthesizer which wants to do audio in ogg vorbis for whatever reason
and says: ``My synthesizer is good but it doesn't fit your requirements
because it supports a more advanced format. Why are your requirements
based on your implementation details?'' or worse ``My synthesizer
supports ogg, your multimedia API supports ogg, but still I can't
use ogg. Why is that?''.
I suggest keeping the API general enough so that it is not dependent
on particular formats (having explicit entry for audio_lenght in the
header, having an entry for audio format name, reporting all times
in miliseconds and not samples) and only limit our implementation
for non-compressed audio for now.
> I have some spelling and wording changes I will post in a separate message.
Perhaps you can commit them in CVS directly unless it is something
controversial.
Thank you,
Hynek Hanke
More information about the accessibility
mailing list