The default bug view has changed. See this FAQ.

The speed slider in narrate could be more useful

RESOLVED FIXED in Firefox 48

Status

()

Toolkit
Reader Mode
RESOLVED FIXED
a year ago
5 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)

(Reporter)

Description

a year ago
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.