Closed Bug 788005 Opened 8 years ago Closed 8 years ago
Output of <Audio> Element is choppy in Windows Vista
User Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20100101 Firefox/15.0 Build ID: 20120824154833 Steps to reproduce: Play any <audio> element. Actual results: Audio output periodically decreases in volume, accompanied by loud clicking noises. When playing a sound for an extended period, the problem is diminished, but does not go away entirely. This appears to occur regardless of the file type. I've tested WAV, Ogg Vorbis and Opus. Audio played by the <video> element seems unaffected. CPU usage appears normal during playback. This issue is a regression in Firefox 15 on Windows Vista. I do not have this problem on my Windows 7 computer at work. Expected results: Audio should playback normally without sputtering or clicking noises.
Component: Untriaged → Video/Audio
Product: Firefox → Core
Thanks for the bug report. What are the hardware specs and sound card/drivers on the Vista machine? A quick way to get this is to run dxdiag and attach the text file it creates when you click "save all information". Can you please test http://flim.org/~kinetik/sync.webm and http://flim.org/~kinetik/sync_a.webm and let me know the results? The first file is a video (with audio) test, and the second is the audio-only portion of the same test. After that, go to about:prefs and create an integer pref named "media.cubeb_latency_ms" and retest with the pref set to 200 and 500 and let me know if either of those settings makes any difference.
No Pref: = sync.webm = 00:04:59.26 00:05:00;04 008996 No audio or visual anomalies, save a tiny, almost imperceptible burst of static at the very instant the video began. = sync_a.webm = Same problem I mentioned before for the entire length of the audio. media.cubeb_latency_ms = 200: = sync.webm = No change. = sync_a.webm = Same problem. No change. media.cubeb_latency_ms = 500: = sync.webm = No change. = sync_a.webm = Same problem. No change.
From Duplicate Bug #788469: The first file (http://www.jplayer.org/audio/ogg/TSP-01-Cro_magnon_man.ogg) has the same issues as other sound files I've tested. The second file (http://static.boomkat.com/oggs/573961.oga) is kinda odd. It starts out slowed down, but the speed up to normal speed after a few seconds. It also exhibits nearly no static.
Thanks, that's helpful. And sorry to waste your time... but I forgot that the pref doesn't work until Firefox 16 (due to an issue fixed in bug 765524). Did you test against 15 or a later version? If you tested the above against 15, would you mind testing against 16 (or, ideally, a nightly)? As one additional test, please create the boolean pref "media.use_cubeb" and set it to false. That'll revert to the old audio backend we used in Firefox 14 and earlier.
I can reproduce this in a Vista SP2 x86 VM inside Virtualbox. Curiously, it didn't seem to reproduce with SP1 (while installing and updating the VM). sync.webm plays fine. sync_a.webm (audio only) underruns frequently (causing it to sound slow and click during buffer transitions). The problem isn't present with media.use_cubeb=false, and media.cubeb_latency_ms=160 seems to be sufficient to cause the problem to disappear, too. I'd be curious to know if that latency setting (or any higher one) is enough to hide this problem for Matthew and James. The fact that this is audio makes me suspect that the root cause is a bad interaction between cubeb's buffer sizing and the audio-only buffering behaviour of the decoder... but I'm surprised it has only been noticed on Vista.
Assignee: nobody → kinetik
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(In reply to Matthew Gregan [:kinetik] from comment #7) > The fact that this is audio makes me suspect that the root cause is a bad > interaction between cubeb's buffer sizing and the audio-only buffering > behaviour of the decoder... but I'm surprised it has only been noticed on > Vista. Or possibly an issue with the minimum attainable audio latency in Vista combined with some luck with buffering in the video case, since dropping the latency to 80 or 90 causes audio playback for sync.webm to stutter too.
I'm using Vista SP2. When I download and install Firefox 16 Beta and add the media.cubeb_latency_ms=200 config setting, the problem goes away for all files listed in this bug. Ogg Opus and WAVE PCM files also play fine. I'll check to see if media.use_cubeb=false works on Firefox 15...
Using media.use_cubeb=false fixes the problem on Firefox 15.
We had a reported of this in the Opus irc channel. Switching to the old backend solves it. The impacted system is running "Vista x32 SP1, Firefox 15.0.1, and sound is the popular Realtek ALC888"
I have problems with "fast playback" of OGG files since Firefox 15. Please see example: http://gr.ema.lv/andris/_soundTest_/ This bug may be relevant to the problem in example.
(In reply to rikijs.murgs from comment #13) > I have problems with "fast playback" of OGG files since Firefox 15. > Please see example: http://gr.ema.lv/andris/_soundTest_/ > This bug may be relevant to the problem in example. It's a different bug, see Bug 793024.
This StackOverflow post from one of the Windows audio developers sheds some light on the XP vs Vista vs Windows 7 differences in waveOut: http://stackoverflow.com/a/1318996 Testing in my Vista SP2 VM with a modified libcubeb that uses 10 buffers instead of 4 (with a default latency of 100ms, so 1 buffer ≈ 10ms duration), I see regular bursts of 3-7 buffers released to cubeb within 1ms, which are all refilled and resubmitted via waveOutWrite within 2-3ms. With a video, the bursts are much smaller (1-2 buffers at a time). In both cases, we're refilling buffers within a handful of milliseconds of them becoming free, and plenty of audio data is queued for playback in the upstream nsBufferedAudioStream (i.e. we're not underrun and writing silence at that level in either case). The difference in size in buffer release bursts seems to be caused by scheduling/timing differences that are tickled by the state machine's timer use (on a different thread). For videos, the state machine sleeps for one frame duration (so ~30ms for this test file). With audio we use AUDIO_DURATION_USECS (40ms) as a default sleep duration for the state machine. In a build with AUDIO_DURATION_USECS set at 10ms, the buffer release behaviour is consistently in small bursts of 1-2 during playback. This doesn't make much sense to me. I initially suspected the timer/scheduler resolution (via timeBeginPeriod) was changing in some cases, so I forced the minimum period (timeBeginPeriod(1)) and reran my experiments, but came up with the same results. I've got a couple of other experiments to follow up on, but I suspect the only fix I'm going to be able to come up with is to wind the latency up to at least 150ms on Vista.
This should deal with Vista and bug 797517: https://tbpl.mozilla.org/?tree=Try&rev=1a1b57f29d53
Oops, build error due to a missing include for my debug printf. New try push (already complete): https://tbpl.mozilla.org/?tree=Try&rev=dea67cb72a59 Test builds are available here: http://email@example.com/try-win32/ Feedback from anyone suffering from this bug would be much appreciated.
(In reply to Matthew Raymond from comment #9) > I'm using Vista SP2. When I download and install Firefox 16 Beta and add the > media.cubeb_latency_ms=200 config setting, the problem goes away for all > files listed in this bug. Ogg Opus and WAVE PCM files also play fine. I'll > check to see if media.use_cubeb=false works on Firefox 15... I've found that using Firefox 16.0.2, with Vista SP2 and observing the same problems as described, adding the above setting clears the issue up completely for me, too.
Detect certain environmental conditions (running on Vista, or inside an RDP session) and return a minimum latency suitable for that environment. Use that to force the requested latency up to the minimum when necessary. This is a bit of tail chasing, but a better solution (dynamic latency, increasing as necessary) will have to wait for another day.
Attachment #680942 - Flags: review?(chris.double)
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
You need to log in before you can comment on or make changes to this bug.