RE: TTS append / queueing

Yes, that would work, though  I'd like to think about the details.  For
example, the current proposal is to use a URI parameter to direct the
browser to a remote resource.  Presumably the page author could switch
engines by changing the value of that parameter (and setting it to null
to indicate the browser's default engine.)  But we wouldn't want to let
the author switch engines in the middle of an utterance, would we?  So
maybe that URI parameter gets pushed down into the utterance structure.
(Or, alternatively, the URI could be passed as an extra parameter in the
call that sets the utterance.)

 

-          Jim

 

From: Dominic Mazzoni [mailto:dmazzoni@google.com] 
Sent: Wednesday, April 25, 2012 10:58 AM
To: Jim Barnett
Cc: Hans Wennborg; public-speech-api@w3.org
Subject: Re: TTS append / queueing

 

On Wed, Apr 25, 2012 at 7:32 AM, Jim Barnett
<Jim.Barnett@genesyslab.com> wrote:

	I could imagine a situation in which a page invoked multiple
distinct TTS engines (expertise in different languages being one common
use case), so I wouldn't want the TTS object to be unique, but I think
it would make sense to have a single TTS object for each engine and then
have a method like  'addUtterance' with the kind of behavior that
Dominic mentioned (queue vs abort, plus the possibility for different
voices/parameters for each utterance.)

 

I agree about wanting to use multiple engines, but why not just make
that a parameter? Unless you wanted two engines talking *at the same
time*, I don't see any reason you need a separate instance per engine.

 

I can see it working where there's a single global TTS object and
everything is done via method calls. That's what we did for the Chrome
TTS extension API. I can also see it working to create one object per
utterance, because a typed JavaScript object is a convenient container
for state. But somewhere in-between (multiple TTS objects per engine,
but not one object per utterance) seems overcomplicated.

 

- Dominic