[fdo] Re: TTS API

[Janina Sajka]

Willie Walker writes:
> >    WW> BTW, an overlying problem that needs to be worked out across 
> >the
> >    WW> whole OS is the notion of managing contention for the audio
> >    WW> output device.  For example, do you queue, mix, cancel,
> >    WW> etc. muiltiple audio requests?  This situation will happen very
> >    WW> frequently in the case of an OS that plays audio when windows
> >    WW> appear and disappear - this behavior causes contention with a
> >    WW> screen reader that wants to also say the name of the window 
> >that
> >    WW> was just shown.
> >
> >IMO no need to care about this, we can expect the speech enabled 
> >desktop
> >is properly configured.
> 
> One would hope.  In the past month, however, I've seen evidence to the
> contrary.  Us engine providers are on the front line -- my comments to
> this group are based on real world experiences and requests from real
> users (I'm guessing your comments are, too, so please don't take my
> comment as a back-handed attack -- I mean nothing of the sort).
> 
> Perhaps as an addendum to the requirements document, we need to make a
> list of assumptions.  One such assumption is this one.

May I suggest splitting the requirements into two documents? One for the
upstream audio server provided by the OS, and the second specific to the
TTS we're focused on? I guess a "list of assumptions" would pretty much
qualify as upstream requirements.

My point is that we should not assume the OS will provide system
services as we would like them. Rather, we should be prepared to state
unambiguously what we believe the OS should be providing to us. In
particular, we should not assume that functionality more appropriately
provided upstream will be present if we have not submitted a specific
requirement for it. We cannot assume that our requirements will mesh
exactly with the requirements of other users.

Thoughts?

				Janina