Closed Bug 1730499 Opened 3 years ago Closed 3 years ago

Audio playback is not working since 92.0

Categories

(Core :: Audio/Video: Playback, defect, P1)

Product:
Core
Component:
Audio/Video: Playback
Version:
Firefox 92
Platform:
Unspecified
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
94 Branch
Tracking Flags:
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- unaffected
firefox92 + fixed
firefox93 + fixed
firefox94 + fixed

People

(Reporter: baishi, Assigned: padenot)

References

(Regression)

Details

(Keywords: regression)

Attachments

(6 files)

about:support
36.30 KB, text/plain
Details
MediaDecoder:5,nsMediaElement:5,cubeb:5
728.00 KB, text/plain
Details
about:support
35.46 KB, text/plain
Details
Bug 1730499 - Updating cubeb-pulse-rs to revision e9e55a4. r?#cubeb-reviewers
48 bytes, text/x-phabricator-request
Details | Review
Bug 1730499 - mach vendor rust. r?#cubeb-reviewers
48 bytes, text/x-phabricator-request
Details | Review
Bug 1730499 - Backout most of 1687070 from release. r?#cubeb-reviewers
48 bytes, text/x-phabricator-request
pascalc
: approval-mozilla-beta+
RyanVM
: approval-mozilla-release+
Details | Review

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:93.0) Gecko/20100101 Firefox/93.0

Steps to reproduce:

Open firefox
Play any media that has sound. No matter YouTube video or local mp3 or wav file.

Actual results:

Playback of any audio will stuck after a fraction of a second. The sink input looks good on PulseAudio side:
1 sink input(s) available.
index: 11
driver: <protocol-native.c>
flags: START_CORKED
state: RUNNING
sink: 3 <jack_out>
volume: front-left: 65536 / 100% / 0.00 dB, front-right: 65536 / 100% / 0.00 dB
balance 0.00
muted: no
current latency: 0.00 ms
requested latency: 128.00 ms
sample spec: float32le 2ch 48000Hz
channel map: front-left,front-right
Stereo
resample method: speex-float-1
module: 10
client: 4 <Firefox>
properties:
media.name = "Best TV News Bloopers Fails #1 - YouTube"
application.name = "Firefox"
native-protocol.peer = "UNIX socket client"
native-protocol.version = "34"
application.process.id = "3491"
application.process.user = "user"
application.process.host = "localhost"
application.process.binary = "firefox-bin"
application.language = "C"
window.x11.display = ":0"
application.process.machine_id = "c8a04699d4ad48e594a6eb1d091da8a3"
application.process.session_id = "1"
module-stream-restore.id = "sink-input-by-application-name:Firefox"
However the playback will stuck forever, looks like the write to the sink is blocked. I can hear a pop sound in the speaker, so the write seemed successful but it could not continue. Killing PulseAudio will allow the video to play without audio. I have tested Chromium on the same machine and Debian firefox-esr (78.12). Both worked without a flaw. Tried to restart the machine and remove .mozilla and .config/pulse folder. Nothing changes.

Tried to change Playback device to Alsa or Jackd. Nothing changes.

Expected results:

Media plays back with audio.
Tried to download Firefox beta 93.0, exactly the same behavior.

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core

:kinetik, could you help look at this?

Flags: needinfo?(kinetik)

I'll bounce this to Paul as I'm on PTO. Given this appeared in 92, bug 1687070 may be related.

Flags: needinfo?(kinetik) → needinfo?(padenot)
See Also: → 1687070

To add a little info, the bug I reported does not related to the length of the audio, even the infinite audio generator such as this one experience the same issue:
https://www.szynalski.com/tone-generator/

I'm uploading more debug info in a minute.

Attached file about:support —
Attached file about:support — 
I also have same problem with 92.  Video plays if no audio (per duplicate bug), but audio blocking everything.

Reporters, can you post here your pulseaudio version ?

Flags: needinfo?(padenot)
Flags: needinfo?(billshopping123)
Flags: needinfo?(baishi)

(In reply to Paul Adenot (:padenot) from comment #9)

Reporters, can you post here your pulseaudio version ?

1:11.1-1ubuntu7.11

Flags: needinfo?(billshopping123)

(In reply to Paul Adenot (:padenot) from comment #9)

Reporters, can you post here your pulseaudio version ?

I suffer from the same problem, but I do not have PulseAudio installed, I have Pipewire

pipewire
Compiled with libpipewire 0.3.35
Linked with libpipewire 0.3.35

(In reply to Paul Adenot (:padenot) from comment #9)

Reporters, can you post here your pulseaudio version ?

Both Pulseaudio 15.0 and Pipewire 0.3.35, so it's not a bug of Pulseaudio.

OS: Unspecified → Linux
Summary: Audio playback is not working with PulseAudio since 92.0(?) → Audio playback is not working since 92.0

(In reply to Paul Adenot (:padenot) from comment #9)

Reporters, can you post here your pulseaudio version ?

pulseaudio 14.2

Flags: needinfo?(baishi)

Some 10c if that gives a hint.

My coworker's computer running Ubuntu 20.xx and Firefox 92 with PulseAudio 14.x is not suffering from this at all. It might be related to some system specific default settings of the audio server.

I'm running Debian bullseye. And as far as I recall, Firefox 91 experience this problem every 3 or 4 days after I leave the workstation running overnight. But it recovers when I restart Firefox. Firefox 92 guarantees to stuck every single instance.

I'm on Manjaro latest.
Tried pulseaudio, pipewire. Tried reinstalling ffmpeg, and compiled AUR/ffmpeg-full. I also removed Firefox, deleted my profile and reinstalled fresh to no avail
I have same problem, no audio. ffmpeg backend hangs. but in a fresh Manjaro pendrive it works.

I'll attach the log https://pastebin.com/raw/DxMEytWX

I fixed it by removing
~/.mozilla
~/.cache/mozilla
~/.pulse

I'm baffled why I didn't tried that earlier

(In reply to mbarriolinares from comment #19)

I fixed it by removing
~/.mozilla
~/.cache/mozilla
~/.pulse

I'm baffled why I didn't tried that earlier

This did not work for me.

While trying this out, I also tried deleting ~/.config/pipewire.

I did not have ~/.pulse, but ~/.config/pulse, which I deleted.

(In reply to mbarriolinares from comment #19)

I fixed it by removing
~/.mozilla
~/.cache/mozilla
~/.pulse

I'm baffled why I didn't tried that earlier

edit: Good catch, Remove this directories
~/.config/pipewire
~/.config/pulse
~/.mozilla
~/.cache/mozilla
~/.pulse

(In reply to mbarriolinares from comment #19)

I fixed it by removing
~/.mozilla
~/.cache/mozilla
~/.pulse

I'm baffled why I didn't tried that earlier

This didn't work for me :-( I don't have pipewire either.

I'll have a patch up for this today, thanks all for confirming. It still isn't clear to me why it works for most people (this went unnoticed for a full Nightly + Beta cycle, about 2 months !), but it really is broken for some installations.

It doesn't seem to be related to pulse version/pipewire presence. I'm also quite surprised that removing a few directory fixes it somehow for at least one person.

I'll revert and adjust the patch that was written to address bug 1687070, hopefully in a way that still fixes it, and uplift to beta and ask for ride along to release. Worst case I'll regress bug 1687070, but it's not as much of a problem that breaking audio completely.

Sorry about all that.

Assignee: nobody → padenot
Status: UNCONFIRMED → NEW
Ever confirmed: true

(In reply to Paul Adenot (:padenot) from comment #23)

I'll have a patch up for this today, thanks all for confirming. It still isn't clear to me why it works for most people (this went unnoticed for a full Nightly + Beta cycle, about 2 months !), but it really is broken for some installations.

It doesn't seem to be related to pulse version/pipewire presence. I'm also quite surprised that removing a few directory fixes it somehow for at least one person.

I'll revert and adjust the patch that was written to address bug 1687070, hopefully in a way that still fixes it, and uplift to beta and ask for ride along to release. Worst case I'll regress bug 1687070, but it's not as much of a problem that breaking audio completely.

Sorry about all that.

Thanks for the quick response - appreciated.

Two builds to test for people having the issue (I still can't reproduce this):

They don't regress bug 1687070 but should (I hope!) sort the issue out. Build 1's patch is slightly nicer, let us know if they solve the issue !

Just untar and run directly the file called firefox in those archives (any distro), after having closed all Firefox instances, e.g.:

tar -xf target.tar.bz2
cd firefox
./firefox

If those don't work, I'll flat out back-out the offending patch to restore the behaviour.

(In reply to Paul Adenot (:padenot) from comment #25)

Two builds to test for people having the issue (I still can't reproduce this):

They don't regress bug 1687070 but should (I hope!) sort the issue out. Build 1's patch is slightly nicer, let us know if they solve the issue !

Just untar and run directly the file called firefox in those archives (any distro), after having closed all Firefox instances, e.g.:

tar -xf target.tar.bz2
cd firefox
./firefox

If those don't work, I'll flat out back-out the offending patch to restore the behaviour.

I've tried both, but neither work for me - sorry. Same as before, circle going around and no progress on youtube videos.

No sound for me too in these builds.

(In reply to mbarriolinares from comment #21)

(In reply to mbarriolinares from comment #19)

I fixed it by removing
~/.mozilla
~/.cache/mozilla
~/.pulse

I'm baffled why I didn't tried that earlier

edit: Good catch, Remove this directories
~/.config/pipewire
~/.config/pulse
~/.mozilla
~/.cache/mozilla
~/.pulse

It didn't work for me.

I don't have pipewire
I don't have .pulse
I removed .mozilla .cache/mozilla .config/pulse
Nothing changed.

(In reply to Bill N from comment #26)

(In reply to Paul Adenot (:padenot) from comment #25)

Two builds to test for people having the issue (I still can't reproduce this):

They don't regress bug 1687070 but should (I hope!) sort the issue out. Build 1's patch is slightly nicer, let us know if they solve the issue !

Just untar and run directly the file called firefox in those archives (any distro), after having closed all Firefox instances, e.g.:

tar -xf target.tar.bz2
cd firefox
./firefox

If those don't work, I'll flat out back-out the offending patch to restore the behaviour.

I've tried both, but neither work for me - sorry. Same as before, circle going around and no progress on youtube videos.

Neither Build1 nor Build2 works for me. I tried each with kill -9 of current firefox instance. rm -rf .mozilla .cache/mozilla .config/pulse and restarted pulseaudio --daemonize=no

Symptom exactly the same, didn't notice any difference.

Ok, interesting, thanks all.

That makes some sense, and apparently I screwed up one of those links last Friday. Here are new ones (I double-checked this time around):

I think build 1 should to work. It's interesting (and annoying) to note that all of those build passed our automated tests, I'm wondering what the difference is. Apparently among the people affected we have a mix of pulseaudio versions, pipewire without pulse, default config or old config, and various distros. It's not clear to me yet.

Thanks for your patience and for checking the builds for me (since I can't check myself). Once I have the confirmation that a particular fix works, I'll make sure it gets to all users as fast as possible.

Sound works for me in Build 1

(In reply to Paul Adenot (:padenot) from comment #30)

Ok, interesting, thanks all.

That makes some sense, and apparently I screwed up one of those links last Friday. Here are new ones (I double-checked this time around):

I think build 1 should to work. It's interesting (and annoying) to note that all of those build passed our automated tests, I'm wondering what the difference is. Apparently among the people affected we have a mix of pulseaudio versions, pipewire without pulse, default config or old config, and various distros. It's not clear to me yet.

Thanks for your patience and for checking the builds for me (since I can't check myself). Once I have the confirmation that a particular fix works, I'll make sure it gets to all users as fast as possible.

Both work for me.

(In reply to Paul Adenot (:padenot) from comment #30)

Ok, interesting, thanks all.

That makes some sense, and apparently I screwed up one of those links last Friday. Here are new ones (I double-checked this time around):

I think build 1 should to work. It's interesting (and annoying) to note that all of those build passed our automated tests, I'm wondering what the difference is. Apparently among the people affected we have a mix of pulseaudio versions, pipewire without pulse, default config or old config, and various distros. It's not clear to me yet.

Thanks for your patience and for checking the builds for me (since I can't check myself). Once I have the confirmation that a particular fix works, I'll make sure it gets to all users as fast as possible.

Works perfectly for me! Will the fix be included in the next release for Firefox 93 ?

Changing severity to S1 because not being able to play any audible file is a serious problem.

Severity: -- → S1
status-firefox92: --- → affected
status-firefox93: --- → affected
status-firefox94: --- → affected
tracking-firefox93: --- → ?
tracking-firefox94: --- → ?
Priority: -- → P1
Has Regression Range: --- → yes

Will the fix be included in Firefox 92.0.1 ?

Right now, the target is to ship a fix in 93. We can consider getting a fix into 92.0.1 also depending on the timing of a patch being made available and the relative complexity and risk in taking it. In other words, we're open to the possibility but can't make any guarantees at this time :-)

Depends on D126188

(In reply to Paul Adenot (:padenot) from comment #30)

Ok, interesting, thanks all.

That makes some sense, and apparently I screwed up one of those links last Friday. Here are new ones (I double-checked this time around):

I think build 1 should to work. It's interesting (and annoying) to note that all of those build passed our automated tests, I'm wondering what the difference is. Apparently among the people affected we have a mix of pulseaudio versions, pipewire without pulse, default config or old config, and various distros. It's not clear to me yet.

Thanks for your patience and for checking the builds for me (since I can't check myself). Once I have the confirmation that a particular fix works, I'll make sure it gets to all users as fast as possible.

Hi Paul,

This is to confirm both builds work for me. I even copied my profile and cache files back and they both worked without any problem. There is no debug output for build1, on the other hand I saw below outputs in console:
CORK
CORKED
PREROLL
PREROLL OK
CALLBACK
CALLBACK
...( lots of CALLBACK)

Please let me know if I can offer any help to troubleshoot the exact reason for this as I have a constant reproducible setup.

This is to be expected, and those debug printouts won't ship. It was to help diagnose should none of those build work. Build 1 is almost what will ship in fact.

Comment on attachment 9242225 [details]
Bug 1730499 - Backout most of 1687070 from release. r?#cubeb-reviewers

Beta/Release Uplift Approval Request

  • User impact if declined: No audio for some users on 92.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This is a backout to revert to the code in 91. Besides, writing the "real" patch for central has brought enough insight into this problem to be able to be confident about this. This was green on try all along, because it is configuration specific, but we have 100% of confirmation that this fixes it for users.
  • String changes made/needed:
Attachment #9242225 - Flags: approval-mozilla-release?

Comment on attachment 9242225 [details]
Bug 1730499 - Backout most of 1687070 from release. r?#cubeb-reviewers

Beta/Release Uplift Approval Request

See https://bugzilla.mozilla.org/show_bug.cgi?id=1730499#c42. The alternative is taking the other two patches in this bug, they graft cleanly on beta.

Attachment #9242225 - Flags: approval-mozilla-beta?
Pushed by padenot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/90072c174d62
Updating cubeb-pulse-rs to revision 5aea956e1. r=cubeb-reviewers,chunmin
https://hg.mozilla.org/integration/autoland/rev/d8017725186e
mach vendor rust. r=cubeb-reviewers,chunmin

Comment on attachment 9242225 [details]
Bug 1730499 - Backout most of 1687070 from release. r?#cubeb-reviewers

Approved for uplift in 93 beta 8, thanks!

Attachment #9242225 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

https://hg.mozilla.org/releases/mozilla-beta/rev/102818a72cf5
(uplifted in beta early to make sure we have it in the upcoming beta 8 build)

status-firefox93: affected → fixed

https://hg.mozilla.org/mozilla-central/rev/90072c174d62
https://hg.mozilla.org/mozilla-central/rev/d8017725186e

Status: NEW → RESOLVED
Closed: 3 years ago
status-firefox94: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 94 Branch

Hi, the fix we're looking at potentially taking in Firefox 92.0.1 is now available in Firefox 93.0b8. Can you please try it out and confirm that things are working as expected for you? It would be greatly helpful. Thanks in advance!

Flags: needinfo?(tohan.marchand)
Flags: needinfo?(otaku)
Flags: needinfo?(baishi)

(In reply to Ryan VanderMeulen [:RyanVM] from comment #48)

Hi, the fix we're looking at potentially taking in Firefox 92.0.1 is now available in Firefox 93.0b8. Can you please try it out and confirm that things are working as expected for you? It would be greatly helpful. Thanks in advance!

93.0b8 works for me

Backed out for causing build bustages

Flags: needinfo?(padenot)
Status: RESOLVED → REOPENED
status-firefox94: fixed → ---
Resolution: FIXED → ---
Target Milestone: 94 Branch → ---
Attachment #9242215 - Attachment description: Bug 1730499 - Updating cubeb-pulse-rs to revision 5aea956e1. r?#cubeb-reviewers → Bug 1730499 - Updating cubeb-pulse-rs to revision e9e55a4. r?#cubeb-reviewers
Pushed by padenot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/68c95d773371
Updating cubeb-pulse-rs to revision e9e55a4. r=cubeb-reviewers,chunmin
https://hg.mozilla.org/integration/autoland/rev/a069ce12654e
mach vendor rust. r=cubeb-reviewers,chunmin

... is now available in Firefox 93.0b8. Can you please try it out and confirm that things are working as expected for you?

Where can i download it?

Flags: needinfo?(otaku)

(In reply to otaku from comment #53)

Where can i download it?

https://www.mozilla.org/firefox/channel/desktop/ is the main location. It's also available in the Snap Store.

(In reply to Ryan VanderMeulen [:RyanVM] from comment #54)

(In reply to otaku from comment #53)

Where can i download it?

https://www.mozilla.org/firefox/channel/desktop/ is the main location. It's also available in the Snap Store.

It says it's updated at September 7 so i think it doesn't contain the fix.

https://hg.mozilla.org/mozilla-central/rev/68c95d773371
https://hg.mozilla.org/mozilla-central/rev/a069ce12654e

Status: REOPENED → RESOLVED
Closed: 3 years ago → 3 years ago
status-firefox94: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 94 Branch

Comment on attachment 9242225 [details]
Bug 1730499 - Backout most of 1687070 from release. r?#cubeb-reviewers

Approved for 92.0.1.

Flags: needinfo?(tohan.marchand)
Flags: needinfo?(padenot)
Flags: needinfo?(baishi)
Attachment #9242225 - Flags: approval-mozilla-release? → approval-mozilla-release+

https://hg.mozilla.org/releases/mozilla-release/rev/d7bbc5812f7f

Status: RESOLVED → REOPENED
status-firefox92: affected → fixed
Resolution: FIXED → ---

Bad Bugherder.

Status: REOPENED → RESOLVED
Closed: 3 years ago → 3 years ago
Resolution: --- → FIXED

Hello. I am now on Firefox 100 and this bug is still a problem for me. It's unclear if the fix was removed / backed out? Please advise

Hi. This was fixed and is working fine for me on FF 100. Perhaps something else?

i can see in Paul's fix that it was about threads / mutexes in the rust layer of the pulse audio. However when i compiled cubeb (the actual c++ library underneath that). Tried that last night it did the same thing with their test programs.

So I have now raised a new issue about it on cubeb repo here:

https://github.com/mozilla/cubeb/issues/706

cubeb in Firefox uses a PulseAudio backed written in rust, available here: https://github.com/mozilla/cubeb-pulse-rs. It has a lot more fixes than the C backend that is deprecated.

ah thanks for clarifying / correcting me on that Paul. So sorry i just assumed here that firefox is still using the mozilla/cubeb c++ backend because it still looks like quite a lot of ongoing activity over there. but presumably now that is more for any other random projects external to mozilla and no longer to do with firefox going forwards?

this then raises (for myself) new questions. such as: will firefox ever support pipewire audio in the future? would that have to be implemented in rust too? in which case maybe rust libs are not mature enough for that to be possible yet?

ok nevermind.... all of my follow up questions have already been fully answered over on the cubeb-rs landing page https://github.com/mozilla/cubeb-rs

many thanks

(In reply to dreamcat4 from comment #64)

ah thanks for clarifying / correcting me on that Paul. So sorry i just assumed here that firefox is still using the mozilla/cubeb c++ backend because it still looks like quite a lot of ongoing activity over there. but presumably now that is more for any other random projects external to mozilla and no longer to do with firefox going forwards?

this then raises (for myself) new questions. such as: will firefox ever support pipewire audio in the future? would that have to be implemented in rust too? in which case maybe rust libs are not mature enough for that to be possible yet?

We only have two rust backends (pulse + macos coreaudio), also we are rewriting the remaining ones in Rust (next one should be Windows/WASAPI). The cubeb API is still C, and there are good bindings for using cubeb from Rust. Firefox uses both the C API and the Rust bindings. I've seen other projects use both as well.

I don't see why we wouldn't have a native pipewire backend, although it's not clear to me what we would gain from it. But if we write a backend, we'll do it in rust for sure, yes, it's a lot simpler.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: