User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0a1) Gecko/20110618 Firefox/7.0a1
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:7.0a1) Gecko/20110618 Firefox/7.0a1
Playback stutters near the end of any WebM video.
Steps to Reproduce:
1. Download the WebM video from the attachment to your local machine.
2. Open it in Firefox.
3. For comparision, open this video in any media player software which supports WebM.
Playback stutters at the end of the video, it sounds like "Mmm...Nah-ah!"
Smooth playback, sounding like "Mmm...Nah!"
Created attachment 540320 [details]
Sample WebM video showing the problem
Firefox 7 x64 confirm
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.2) Gecko/20110508 Firefox/7.0a1 ID:20110618030732
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110202 Firefox/4.0b12pre ID:20110202155857
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110202 Firefox/4.0b12pre ID:20110202173919
SeaMonkey 2.4a1 (20110619003048) confirmed.
In local build:
build from ee00364d3092 : fails
build from 5212ab4ae808 : works
ee00364d3092 Chris Double — Bug 607838 - Allow audio drains to be interrupted - r=cpearce a=blocking2.0:final
Mozilla/5.0 (Windows NT 6.2; rv:7.0a1) Gecko/20110618 Firefox/7.0a1
Intel Celeron 2.4Ghz (3.6Ghz), 1Gb RAM, HD4650 1Gb.
In Media Player Classic is played without stuttering.
This only happens on some WebM videos, not all.
Looks like we've got fewer than minWriteSamples of audio written to hardware when we wait for the stream to finish playing before we drain the audio stream.
Options to fix this:
1. Wait for the audio rewrite to land. Not sure how far off that will be.
2. Always write minWriteSamples worth of silence before going into the "sleep until end of audio" loop.
3. Add a sa_stream_flush() function which we call before going into the "sleep until end of audio" loop, that will perform the first half of sa_stream_drain() - on Linux, write minWriteSamples of silence if the stream isn't PREPARED, and on Windows, write the pending blocks.
Matthew: How long until the audio rewrite lands? Is it worth trying to fix this now?
*** Bug 650193 has been marked as a duplicate of this bug. ***
It'll be up for review this week, so it's not worth fixing this independently.
Excuse me for nudging, but "this week" passed some time ago. Is it still planned to implement that audio rewrite thing? Can we expect it in Firefox 8?
The progress is in bug 623444, but it's taking longer than I estimated. At this rate it is likely to be ready near the end of the Firefox 8 nightly cycle, so I would land it for Firefox 9 because it's far too risky to land at the end of a nightly cycle.
That leaves us with this bug, which we can wait on for one more cycle, or attempt to fix with one of the other options Chris laid out above.
Created attachment 552282 [details] [diff] [review]
Patch: Ensure we've written minWriteSamples before sleeping in AudioLoop
Simple fix. Only sleep in AudioLoop() if we've written more than minWriteSamples since the last audio write.
I also changed the logic for sleeping when the AudioLoop() is ahead of the decode to also use this metric. Previously we'd only sleep if AudioLoop() had written at least minWriteSamples since the last sleep.
I had tried using this second measure to fix the problem in this bug, but it didn't work reliably. I think this is because all the audio we wrote since the last sleep could have played by the time we come to evaluate this condition. The only time we really know how much unplayed audio we've written to the hardware is right after we write the unplayed audio to the hardware. So we should use this more reliable metric instead.