Closed Bug 856034 Opened 11 years ago Closed 9 years ago

Ogg video is muted/unmuted with delay

Categories

(Core :: Audio/Video, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox38 --- affected

People

(Reporter: adalucinet, Unassigned)

Details

(Keywords: regression)

Reproducible on Firefox ESR 17.0.5 (BuildID: 20130328110703): Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20100101 Firefox/17.0
Reproducible on the latest Aurora (<BuildID: 20130329042015): Mozilla/5.0 (X11; Linux i686; rv:21.0) Gecko/20130329 Firefox/21.0
Reproducible on the latest Nightly (BuildID: 20130329030904): Mozilla/5.0 (X11; Linux i686; rv:22.0) Gecko/20130329 Firefox/22.0
Reproducible on Firefox 20 RC (Build ID: 20130326150557): Mozilla/5.0 (X11; Linux i686; rv:20.0) Gecko/20100101 Firefox/20.0

Steps to reproduce:
1. Start Firefox.
2. Navigate to www.getpersonas.com and start playing the video.
3. Pause and mute/unmute the video.

Expected results: The video is muted/unmuted without delay.

Actual results: The video is muted/unmuted with delay.

Notes:
1. This issue is a regression - currently working on a regression range.
I was unable to find a reliable range because I couldn't find any release build without this issue; althought in Firefox 14.0.1 I've encountered a bigger delay, so this issue was fixed once but not fully.  Here is the range I've found:

Last good nightly: 2012-04-16
First bad nightly: 2012-04-17

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fd06332733e5&tochange=c61e7c3a232a
(In reply to Alexandra Lucinet [QA] from comment #1)
> Last good nightly: 2012-04-16
> First bad nightly: 2012-04-17
> 
> Pushlog:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=fd06332733e5&tochange=c61e7c3a232a

Is this the regression window for when it got better or when it got worse?
Keywords: regression
The regression window is for when it got better.
Nothing stands out in that range that would have "fixed" this. Perhaps mounting improvements in PGO resulted in this bug appearing to be fixed and mounting regressions in PGO over time has re-regressed this. I'm not sure how we can investigate this further though.

Also, FWIW I'm not able to reproduce this (Firefox 19.0.2, Ubuntu 12.04.2 64-bit).
Is this bug describing the behaviour where, after pausing and then muting, subsequent playback causes a small burst of audio before the mute takes effect?

It's not obvious from the commit messages, but that range does include switching audio backends.  Part of that change moved where volume adjustments are applied, which may explain the change in delay.
(In reply to Matthew Gregan [:kinetik] from comment #5)
> Is this bug describing the behaviour where, after pausing and then muting,
> subsequent playback causes a small burst of audio before the mute takes
> effect?

Yes, that's right.
[testday-20140530]

this problem is on every sound output (video and audio) not just ogg formats

steps to test:
- start video
- pause video
- mute video
- play video (you can hear 1 sec sound)

see also Moztrap test case #11511 and #11513
This regression is over a year old at this point. Any chance we can get some traction on it?
This hasn't been a priority for us, unfortunately. It helps to know it's generally reproducible. Did you have a cubeb theory kinetik?
Flags: needinfo?(kinetik)
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #8)
> This regression is over a year old at this point. Any chance we can get some
> traction on it?

I'm not sure it's a regression, it has probably existed since we added media playback to Gecko.

(In reply to Ralph Giles (:rillian) from comment #9)
> This hasn't been a priority for us, unfortunately. It helps to know it's
> generally reproducible. Did you have a cubeb theory kinetik?

It's not specific to libcubeb.  The root cause is that we adjust the volume of the samples in AudioStream as they're submitted for playback, but Pause/Resume is passed directly through to the OS, so if you Pause, adjust the volume, then Resume, there's some amount of audio still buffered at the old volume (the amount depends on the stream latency).
Flags: needinfo?(kinetik)
The proper fix being to use the platform's API to change the volume when available, and to fallback on what we do now, but in cubeb, for platform that don't offer this.
This is fixed since we now use the platform API for volume (where we can).
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.