W3C home > Mailing lists > Public > public-speech-api@w3.org > April 2012

Re: TTS append / queueing

From: Dominic Mazzoni <dmazzoni@google.com>
Date: Wed, 25 Apr 2012 07:57:35 -0700
Message-ID: <CAFz-FYy47Sd2b60boYqdi_3FH85_dsDP5wkC2UXfTu0emBxJdQ@mail.gmail.com>
To: Jim Barnett <Jim.Barnett@genesyslab.com>
Cc: Hans Wennborg <hwennborg@google.com>, public-speech-api@w3.org
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
Received on Wednesday, 25 April 2012 14:58:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:27:22 UTC