Note: There are a few cases of duplicates in user autocompletion which are being worked on.

The speed slider in narrate could be more useful

RESOLVED FIXED in Firefox 48

Status

()

Toolkit
Reader Mode
RESOLVED FIXED
a year ago
8 months ago

People

(Reporter: Ehsan, Assigned: eeejay)

Tracking

unspecified
mozilla48
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox48 fixed)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment)

Right now we show a slider to control the speed of narration.  The two extremes of this slider can hardly be considered as useful.  I don't have the exact multipliers that they activate but one is way too fast and the other is way too slow for any useful purpose.

Youtube for example offers only a few speed settings: 0.25, 0.50, Normal, 1.25, 1.5 and 2.  Perhaps we can simplify this slider to offer a smaller but more useful set of speed choices?
(Assignee)

Comment 1

a year ago
I noticed that on mac, but not other platforms. Theoretically the slider should be bound at 4x rate in each extreme. I think this may be a bug in mac speech synth. NI'ing Makoto.
Flags: needinfo?(m_kato)
(Assignee)

Comment 2

a year ago
Seems I was wrong..

The real culprit is the wrong rate conversion in Linux, my primary dev platform.
Depends on: 1254738
Flags: needinfo?(m_kato)
(Assignee)

Updated

a year ago
Assignee: nobody → eitan
While you're working on this, can you make the speed update while dragging the slider? I tried using it and thought that it was broken until I released the mouse and then saw the change in speed. Because of this, it is hard to know how fast or slow I am changing the speed until I have already made the decision.

Another thing we can do is to make the slider work in steps. I don't think we need to support speaking at 34.2353% speed for example. We could probably just add steps for 0.25, 0.50, Normal, 1.25, 1.5 and 2 (matching comment #0 and our native video controls). My primary point is to make the slider have "steps".
(Assignee)

Comment 4

a year ago
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #3)
> While you're working on this, can you make the speed update while dragging
> the slider? I tried using it and thought that it was broken until I released
> the mouse and then saw the change in speed. Because of this, it is hard to
> know how fast or slow I am changing the speed until I have already made the
> decision.

That is a limitation of synthesis APIs, you can't often change rate mid-utterance. And even if it wasn't I don't know how that would be usable. Speed is perceived over time, having it instantly change (probably with some lag) would be more confusing, IMHO.

> 
> Another thing we can do is to make the slider work in steps. I don't think
> we need to support speaking at 34.2353% speed for example. We could probably
> just add steps for 0.25, 0.50, Normal, 1.25, 1.5 and 2 (matching comment #0
> and our native video controls). My primary point is to make the slider have
> "steps".

It does. They can be larger though..
Oh okay, thanks for the corrections. Can it snap to those steps while dragging?
I noticed this too on OS X. Also, the speed seems to break in a weird way on non-English articles... If I load up a random page from www.welt.de and speak it, the voice is still unintelligibly fast at the ~80% point, but above that it seems to reset to a normal speed. Not sure if that's a bug, or maybe the underlying OS X code is just treating that as too fast and falling back to the default?

[Also, it's nice that the "default" voice switched to the right language-specific voice!]
(Assignee)

Updated

a year ago
Depends on: 1256521
(Assignee)

Comment 7

a year ago
(In reply to Justin Dolske [:Dolske] from comment #6)
> I noticed this too on OS X. Also, the speed seems to break in a weird way on
> non-English articles... If I load up a random page from www.welt.de and
> speak it, the voice is still unintelligibly fast at the ~80% point, but
> above that it seems to reset to a normal speed. Not sure if that's a bug, or
> maybe the underlying OS X code is just treating that as too fast and falling
> back to the default?

Yup. Some voices will just ignore the rate if it is beyond its capability. I'll provide a patch that has a more conservative speed range that should work with all/most voices.
(Assignee)

Comment 8

a year ago
Created attachment 8731369 [details]
MozReview Request: Bug 1254234 - Make narrate speed slider range more useful. r?Gijs

Review commit: https://reviewboard.mozilla.org/r/40525/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/40525/
Attachment #8731369 - Flags: review?(gijskruitbosch+bugs)
(Assignee)

Comment 9

a year ago
This patch gives the slider a minimum of 0.5x speed, and a max of 2x. It is subjectively the range that I think is useful (0.5x is also the minimal speed in Linux).

There are 4 steps in each direction (eg. 1.25x, 1.5x, 1.75x, 2x).

Comment 10

a year ago
(Sorry, gremlins happened - the code obviously looks fine, as the patch is trivial, but I wanted to actually try this on all 3 platforms so I had an idea what the issue was and what I was r+'ing, but due to said gremlins I did not find time today. First on my list tomorrow.)
(Assignee)

Comment 11

a year ago
It's good you waited. The speech rate is finally consistent on all platforms. I blogged about what I did to assure that: http://blog.monotonous.org/2016/03/17/benchmarking-speech-rate/

Comment 12

a year ago
Comment on attachment 8731369 [details]
MozReview Request: Bug 1254234 - Make narrate speed slider range more useful. r?Gijs

https://reviewboard.mozilla.org/r/40525/#review37607

Alright, let's do it!
Attachment #8731369 - Flags: review?(gijskruitbosch+bugs) → review+

Comment 13

a year ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/ce85118f049d

Comment 14

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/ce85118f049d
Status: NEW → RESOLVED
Last Resolved: a year ago
status-firefox48: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Verified fixed on Windows 7 64bit and Mac OSX 10.9.5 using latest Aurora 48.0a2 (buildID: 20160504004015): there are 4 steps in each direction. 

On Ubuntu, the issue can't be verified since it depends on bug 1270110.
See Also: → bug 1316828
You need to log in before you can comment on or make changes to this bug.