Re: Regarding SpeechSystemUtterance.rate

Hi Andai!

I don't know if I understand proposal A, but as for B, I think you are
describing the current spec:
https://dvcs.w3.org/hg/speech-api/raw-file/tip/webspeechapi.html#dfn-utterancerate

I did a bunch of research in the past about speech rates in the browser,
and worked to get this as right as possible in Firefox.
You can read about that in these two posts:
https://blog.monotonous.org/2016/03/13/normalizing-speech-rate/
https://blog.monotonous.org/2016/03/17/benchmarking-speech-rate/

I wrote a test tool so you can compare browsers/platforms/voices and see if
their rate is truly a multiplier:
http://eeejay.github.io/webspeechdemos/rates.html

Cheers,
 Eitan.


On Thu, Aug 3, 2017 at 9:25 PM, Andai Velican <funnyav@gmail.com> wrote:

> Hi everyone! First of all, if I'm understanding correctly it's thanks to
> you guys that most browsers now support TTS!
> That's super cool, so thanks for that :)
>
>
> tl;dr please make speech rate a multiplier
>
> this will lead to optimal-by-default TTS, so the default rate "1" produces
> output at the user's preferred rate.
>
>
> = the situation =
>
> As far as I can tell, there is no way to determine what the system default
> speech rate is.
> The rate's default value 1 does not reflect the system rate, and there is
> no way to query it.
>
> As a result, there is currently no way to deliver an ideal TTS experience
> through a web browser.
>
> The developer must simply guess what the user prefers.
> The user must manually adjust the rate on every site / app they will ever
> use.
>
> Oh no!
>
>
>
> = suggestion =
>
> (A) implement speechSynthesis.nativeRate and set rate to that value by
> default
>
> (B) or -- much better -- make speech rate a multiplier !
>
> In this case, rate functions as a modifier for the system rate.
>
> So the default value 1 will *equal* the system rate
> 0.5 and 2 will be half and double the normal speed,
> where "normal" is user-dependent (configured in OS TTS preferences).
>
> The rate-multiplier option feels cleaner to me.
> It would not require changing the API.
> Plus, all existing code would continue to work. In fact, it would even
> work *better* :)
>
>
>
> = context / motivation =
>
> Discord (on web and desktop, since it's a web-app either way) does not
> respect the system speech rate.
>
> In Discord, there's no speed slider, so on a busy day (which is every day)
> the spoken conversation starts lagging and never catches up.
> ( next stop: bug Discord devs about that missing speed slider! )
>
> So I did some digging and figured out it was actually because of decisions
> you guys made years ago!
> I don't know if you guys are still involved in this, since it looks like
> most of the work was done a long time ago.
> But I'd be really happy if something were done about this.
>
> The future of optimal-by-default TTS is in your hands!
>
> I don't know C++ or I'd take a stab at it myself
> It might be time to give it a try... :)
>
>
> Thanks so much,
> andai
>
>