User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0 Build ID: 20160708230936 Steps to reproduce: Go to, e.g., https://www.youtube.com/watch?v=1gDhR1R3S0s and play the video. This Actual results: The ad (if any) seems to play fine, but when the song starts, the playback is at ~2x (or greater) speed. Changing the playback rate doesn't fix the problem. Expected results: The video should have played back at normal speed. This started happening a few weeks ago (before the breakage in https://bugzilla.mozilla.org/show_bug.cgi?id=1286527 ) but didn't happen a month or so ago (roughly). Some change in the last month seems to have brought this on.
Same problem here, this bug was introduced in Firefox Nightly 50.0a1.20160702-1 and is still not resolved as of today's nightly 50.0a1.20160717-1. It seems to be occurring on every video, youtube or not. Starting with a new and clean profile and disabling all addons doesn't fix it.
Unable to reproduce bug in OSX Yosemite 10.10.2 using nightly build 50.0a1 (2016-7-18).
User Agent Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0 Build ID 20160719030224 I could not reproduce the issue on latest Nightly (2016-07-19) on Ubuntu 15.04. Considering 2 people already experienced the issue, I'm moving this to a proper component so someone with experience on this matter to be involved.
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
It happens for me on a box running Ubuntu 16.04 (w/ a new 4.7rc7 kernel) using ALSA and jack for the sound output. On another box with an otherwise identical setup, but using PulseAudio, things are fine. Interestingly, this same split (working/not working) was seen with https://bugzilla.mozilla.org/show_bug.cgi?id=1286447 which was failing when trying to call a non-sanbox-approved sys_semop. This was fixed, but now gets me back to the situation with this bug. The history is: 1) things worked fine a month or so ago 2) the playback speed bug showed up (according to NoSohoth on 2106-07-02) 3) the semop bug showed up 4) the semoop bug was fixed 5) now we're back to the playback speed problem I assume there's a different codepath somewhere along the line and that this not only linux specific but alsa-specific. But then again I know little about how mozilla handles audio. Let me know if I can provide any more info.
3 years ago
Component: Audio/Video: Playback → Audio/Video: cubeb
3 years ago
Depends on: 1247056
Perhaps a jack/alsa issue... (as mentioned)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Please test the build available here: http://email@example.com/ and let me know if the issue still exists.
(In reply to Matthew Gregan [:kinetik] from comment #6) > Please test the build available here: > http://firstname.lastname@example.org- > 91fff44e57466d7e300aad15a94843796bccda63/ and let me know if the issue still > exists. Thank you. Your build fixes the issue on my box.
(In reply to Matthew Gregan [:kinetik] from comment #6) > Please test the build available here: > http://email@example.com- > 91fff44e57466d7e300aad15a94843796bccda63/ and let me know if the issue still > exists. Do you have a patch that I can use to try building here? thanks!
(In reply to Cyrus Harmon from comment #8) > Do you have a patch that I can use to try building here? thanks! mozilla-central has half of the fix already, apply this for the other part. These fixes are for bug 1279125, so this bug will probably be duped to that if you find this fix works for you.
The patch on top of the latest mozilla-central tree fixes things for me. Thanks!
Thanks for testing and confirming Cyrus and NoSohoth. I'll dupe this bug to the other one, and get the second part of the fix landed soon.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1279125
I don't have any good hard evidence for this, but it feels like this patch, while fixing the described bug, results in relatively poor performance for other audio tasks. I use jack for audio input/output and when I'm running nightly with this patch, jack becomes unresponsive for long periods of time and stops/reading audio. Quitting nightly makes the problem go away. Like I said, I don't have good hard evidence for this, and it certainly may be due to the general load on the CPU from the browser (and any plugins) but I don't remember things being this bad with older versions of firefox. My fear is that this patch is somehow hobbling alsa/jack and creating problems. I'm happy to to dig into this further if anyone has suggestions on how I might try to track this down. For the moment, the fix is to quit Nightly while using ardour.
The changes in bug 1279125 are working around some other problem, which looks like it's either an ALSA/dmix bug (which either needs to be fixed upstream, or perhaps worked around differently in our code) or a bug in libcubeb's ALSA backend. I've tried to summarize the current state of things here: https://github.com/kinetiknz/cubeb/issues/135 If you'd like to help out, read through the details there and see if you have any ideas. There's a small code sample linked from that GitHub issue to reproduce the issue outside of Firefox, which might make a good starting point for testing alternate workarounds or interfacing with the upstream ALSA developers.
You need to log in before you can comment on or make changes to this bug.