Open Bug 1579700 Opened 6 years ago Updated 3 years ago

No sound on Linux when running PulseAudio through JACK via a sink

Categories

(Core :: Audio/Video: cubeb, defect, P5)

Product:
Core
Component:
Audio/Video: cubeb
Version:
71 Branch
Type:
defect

Tracking

()

People

(Reporter: kirik1007, Unassigned)

Details

(Keywords: regression)

Attachments

(5 files)

jack_no_audio.moz_log
12.00 KB, text/plain
Details
Log 2nd try
5.25 KB, text/plain
Details
pavucontrol with JACK on and off
95.83 KB, image/png
Details
pavucontrol after restarting PulseAudio
106.33 KB, image/png
Details
Log, turning jack off and on
125.69 KB, application/octet-stream
Details
Attached file jack_no_audio.moz_log —

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

Steps to reproduce:

  1. Run PA through JACK via a sink (both PulseAudio AND JACK are running, the output of PulseAudio is being routed to JACK, which then routes the output to the sound card)
  2. Open any media with sound, for example, here I'll be using youtube (https://www.youtube.com/watch?v=jNQXAC9IVRw), but same applies for other media, Twitch, pure sound sites like SoundCloud

Actual results:

Page loads, video freezes on the first frame of the video, doesn't start playing

Expected results:

Video plays

Additional info:

  1. Issue appeared after upgrading from Nightly 70 to Nightly 71, Nightly is installed from official tarballs.
  2. Everything works fine when JACK is not running. Additionally, stopping JACK immediately starts the video.
  3. Same exact use case is working fine on stable Firefox 69

What I tried:

  1. Turning off cubeb sandboxing via setting media.cubeb.sandbox = false in about:config

Also attaching a log of launching Nightly with --MOZ_LOG="MediaStreamGraph:5,cubeb:5", but I can't see any errors in it, just listings of available sinks/sources.
If anyone knows what other logging modules can help narrow down the issue, I'll be thankful

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

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

Hi, Chun-min,
Could you take a look for this bug?

Flags: needinfo?(cchang)

Can you try with media.cubeb.sandbox set to false (make sure to restart after flipping the pref). Thanks for the logs, for this scenario better use:
MOZ_LOG=timestamp,sync,AudioStream:5,cubeb:5

Attached file Log 2nd try —

Logs from starting Firefox with --MOZ_LOG="timestamp,sync,AudioStream:5,cubeb:5" and cubeb sandbox set to false (with restart), going to a youtube video, clicking play, waiting a little bit, then clicking pause then exiting

Attached the log from running Nightly with your recommendations,
Thanks for telling me to restart after toggling cubeb.sandbox, because I didn't know about that, did it this time. But, sadly, didn't work, still experiencing the same issue.

I am not really sure what is going on. I see in the logs that the playback start at 17:15:29 and stops at 17:15:36 (after 7 secs). In between, I see just one audio callback which is the problem. Given that your buffer is 48000 frames long and the rate is 48000 frames per sec I would expect 7 callbacks. Something is blocking the flow at first callback and it never recovers.

One action could be to capture PulseAudio logs [1] in case we see something in there.

A second action is to use mozregression [2] in order to find the commit that created the problem since it was working before.

[1] https://wiki.ubuntu.com/PulseAudio/Log
[2] https://mozilla.github.io/mozregression/

Thanks for the reply, so a couple things

  1. Couldn't get the Pulse logs (yet, if needed I can fiddle with the autostart config) cause as it turns out, restarting Pulse actually fixes the issue, so I
  2. Ran Mozregression and got [1] in the end as the result.

[1] https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e7d500f650ccfe119d46a36392fa641b47c142a2&tochange=790684b8a27c97bac4bb66338c182e8dfecbbf58

P.S. Wow you guys did great work on Mozregression, that was a very pleasant experience

Matthew this is a regression from Bug 1539225. Can you please take a look and tell us what you think?

Flags: needinfo?(kinetik)

Not sure what's going on here. If this still reproduces with media.cubeb.sandbox set to false, I'm not sure how bug 1539225 could have caused this...

The changes in bug 1539225 affect three things:

  1. the name of cubeb streams when the sandbox is enabled (disabled the names are unaffected, enabled the names should match the media.cubeb.sandbox == false case after 1539225 is applied)
  2. whether we honour the media.cubeb.backend pref when sandboxing is enabled (sandboxing disabled already honoured the preference)
  3. the timing of starting the AudioIPC server, which now starts later and only when requested

My guess would've been #1 causing some stream-name-specific configuration difference inside PA that may've been set to make the JACK sink work correctly, but that would only affect the media.cubeb.sandbox == true case.

The fact that restarting the PA server temporarily solves this might suggest this is a PA/config issue, but it's possible we're doing something wrong to trigger this.

@kirik1007, can you please confirm that media.cubeb.backend is not set to any value in about:config? Can you also confirm this issue does reproduce with media.cubeb.sandbox set to false?

If so, it would be very helpful to try mozregression again while media.cubeb.sandbox is false since that may produce a different regression range and give us a clue about the root cause.

Flags: needinfo?(kinetik) → needinfo?(kirik1007)

Sorry for the late response, just got to figuring things out, thanks for the steps, here are the results:

  1. media.cubeb.backend isn't set to anything, neither mozregression nor my regular installed Nightly profile

  2. running with media.cubeb.sandbox set to false, makes this bug appear on every single version of Firefox for me, got as far back as 2015-01-01 (before that it started to not recognize Youtube's video format), and it was still there, couldn't run it

With sandbox set to false, when restarting Pulse, the video doesn't work neither with JACK or pure Pulse, until a restart, and then it works

Kinda disappointed this one didn't bring out anything useful, please tell me if there are any other tests I could run, and thank you so much for taking a look at this.

Flags: needinfo?(kirik1007)

(In reply to kirik1007 from comment #10)

With sandbox set to false, when restarting Pulse, the video doesn't work neither with JACK or pure Pulse, until a restart, and then it works

Not sure if I misunderstand, does it mean:
when media.cubeb.backend is empty, media.cubeb.sandbox is false, and the backend is pure PulseAudio (without being routed),
the youtube video cannot play at first, but video can play if PulseAudio is restarted?

Does the youtube video work in the default audio setting(default settings of the PulseAudio)? or this bug only happens when the audio is being routed?

Flags: needinfo?(cchang)

(In reply to C.M.Chang[:chunmin] from comment #11)

(In reply to kirik1007 from comment #10)

With sandbox set to false, when restarting Pulse, the video doesn't work neither with JACK or pure Pulse, until a restart, and then it works

Actually I'm really sorry, and I misreported that, was talking about restarting Nightly in the "until a restart" part, but I tried to reproduce this again, and video actually still plays the moment I turn JACK off, without the need to restart Nightly nor Pulse

when media.cubeb.backend is empty, media.cubeb.sandbox is false, and the backend is pure PulseAudio (without being routed),
the youtube video cannot play at first, but video can play if PulseAudio is restarted?

The video plays perfectly when it's pure PulseAudio, the moment I turn on JACK and it starts routing, playback stops
Turning off JACK and falling back to pure PA resumes playback
If after this I restart PulseAudio, the issue automagically disappears and playback works with both pure PA and JACK routing, and it keeps working until system reboot

I do have PA on autospawn and it might be reconfiguring itself in a slightly different way when I restart, so this might also be a factor.
Honestly it feels like I'm the only one who got hit by this judging by what I've tried to suss out from googling, looking at arch wiki and a bunch of subreddits (didn't peruse any mailing lists), so I'm content with chalking it up to a misconfiguration somewhere and just throwing in a pulseaudio -k && pulseaudio --start somewhere in my .bashrc and be done, however I will still run whatever tests needed and I REALLY appreciate you guys taking a look at this

Does the youtube video work in the default audio setting(default settings of the PulseAudio)? or this bug only happens when the audio is being routed?
Only when it's being routed, pure PA is working fine

If I understand correctly:

  • All Firefox versions, cubeb sandboxing enabled or disabled, works fine with default PA
  • All Firefox versions, cubeb sandboxing enabled or disabled, fail with the JACK PA sink except Nightly 69

So the only case where the JACK PA sink works for you is Nightly 69 with cubeb sandboxing enabled?

Would you mind attaching screenshots of pavucontrol showing the Firefox streams for both the working (via JACK) and broken case, please?

(In reply to Matthew Gregan [:kinetik] from comment #13)

If I understand correctly:

  • All Firefox versions, cubeb sandboxing enabled or disabled, works fine with default PA
  • All Firefox versions, cubeb sandboxing enabled or disabled, fail with the JACK PA sink except Nightly 69

Almost, right now it's like this
Y - works, N - doesn't work

sandboxing disabled (false)

------- Pure PA Routing Through JACK
Before fix for 1539225 Y N
After fix Y N

sandboxing enabled (true)

------- Pure PA Routing Through JACK
Before fix for 1539225 Y Y
After fix Y N

So:

  1. Pure PA works
  2. If sandboxing is off, routing through JACK never worked correctly
  3. If sandboxing is on, routing through JACK worked UNTIL the bugfix

Forgot to add about the screenshot, this is done on a current-ish Nightly (2019-09-04) with sandboxing turned on.

And here is pavucontrol after I restart pulseaudio.

Actually seems like there's a difference, because in this one the playback goes to the JACK sink, while before the restart it tries going straight to the soundcard

Instead of restarting, if you manually change the Nightly AudioStream in pavucontrol to use the jack sink, does it make things work too?

I'm not sure how we pick up which output device is the default, but on Ubuntu we automatically switch when I use the "Sound" panel in "Settings" to select default device. Selecting a device in pavucontrol with the green checkmark "Set as fallback" does not work.

If I diff pacmd list-sinks between having two different devices selected I see the default device has state: RUNNING and the other state: SUSPENDED. Could you check the state of your sinks when it doesn't work?

Doing pacmd set-default-sink <sink> from the command line makes the device show as default in Sound Settings appropriately, but sound still plays from the same sink as before. Others probably now better how to properly change sink on the fly from a terminal.

Also, this sounds like this issue: https://wiki.archlinux.org/index.php/PulseAudio/Examples#When_JACK_is_started_Firefox,_Chrome_and_other_apps_stop_playing_video_and_audio

(In reply to Andreas Pehrson [:pehrsons] from comment #17)

Also, this sounds like this issue: https://wiki.archlinux.org/index.php/PulseAudio/Examples#When_JACK_is_started_Firefox,_Chrome_and_other_apps_stop_playing_video_and_audio

Wow, I feel dumb for not having noticed that particular thing in the arch wiki, mainly cause I was looking at JACK page and not PulseAudio's, but that's exactly my situation.

If I switch manually in pavucontrol the sink from the soundcard to the JACK sink, the video starts playing, thanks!

Doing pacmd list-sinks when JACK is running, my soundcard is always SUSPENDED
However, the JACK sink shows up in the list with the * on it, which I assume means that it's the default, so it seems that Firefox doesn't respect the default settings somehow? Mind you, it shows up like this even before I set it as default with set-default-sink

On another note, I seem to have figured out, why it works after restarting PulseAudio:
When I restart it, it spawns back with the JACK sink active, but there is no soundcard, I assume because it's still suspended by JACK, so Firefox starts playing to the JACK sink.
If I then shut down JACK, the soundcard shows up in pavucontrol, the JACK sink disappears, the playback falls back to the soundcard, everything's great
BUT
If I then turn on JACK, the soundcard doesn't disappear, the JACK sink appears, but Firefox doesn't switch to the sink and tries to keep on playing on the suspended soundcard, the playback stops, and we're back to the issue I had in the first place

Priority: -- → P5

(In reply to kirik1007 from comment #18)

If I then turn on JACK, the soundcard doesn't disappear, the JACK sink appears, but Firefox doesn't switch to the sink and tries to keep on playing on the suspended soundcard, the playback stops, and we're back to the issue I had in the first place

You could try capturing cubeb logs again to check if we get a device change notification when jack is turning on.

(In reply to Alex Chronopoulos [:achronop] from comment #19)

You could try capturing cubeb logs again to check if we get a device change notification when jack is turning on.

Attaching a log, from what I see, the notifications arrive correctly, but FF doesn't switch to the new sink.

What I did:

  1. (08:22:01) Launch Firefox with JACK turned on and opened a video, no playback
  2. (08:22:11) Stopped JACK, FF falls back to PulseAudio and starts playing, you can see that the sinks/sources for JACK disappear
  3. (08:22:22) Start JACK back again, the sinks/sources appear in the log, but nothing else happen, the playback gets stuck, nothing more gets written to logs
  4. about 3-4 seconds later I quit firefox (with Ctrl+Q)

Also on another note, since I might just be having a weirdly (mis)configured PulseAudio/JACK, even though I don't remember doing any big changes from Arch's default, I actually have the same kinds of issues with a big chunk of steam games, they too seem to favor binding playback to the soundcard, instead of the jack sink.
However, a lot of other programs, Audacity, Chromium and anything Electron-built, mpv work correctly

Please make sure that the newly added sink in step 3 is the default one, or make it the default one, to force a sink switch. Alternatively, a sink switch will happen if the one being used is removed.

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression

The sink is set as the default one, I think, it has the * near the index in pacmd list-sinks, and in KDE's sound prefs it's listed as the top priority, also in pavucontrol it always gets set as "use as fallback" when JACK starts.
I'm not super well versed in PA's configuration, so if there's any other place I'm missing, then please tell me

Firefox not switching to a new default sink sounds like a bug, but I'm not immediately sure what would cause that.

I think I can reproduce the same issue by doing: pactl load-module module-null-sink sink_name=dummy then pactl set-default-sink dummy. The default output device shown in Gnome Sound changes, but Firefox doesn't move to this device automatically during playback (even if I start a new stream) but does use the new sink after restarting.

Although the second time I tried this (after unloading the null sink and reloading it), Firefox switched immediately after I changed the default sink... so there's a piece of the puzzle missing here.

I think the initial issue was caused by your Firefox streams using the JACK output explicitly (possibly via picking it up as the default when it was first configured, then being restored via module-stream-restore or a similar mechanism), which stopped working when bug 1539225 changed the context/stream names for remoted streams to match the old/intended naming that predated remoting. We might be able to confirm this if you use tdbdump (part of tdb-tools on Fedora, not sure for Arch) to dump $HOME/.config/pulse/*-stream-volumes.tdb (path might be different, and filename will be prefixed with a hash).

I'll mark this as confirmed, since it seems there's something to investigate and fix around default sink switching in Firefox.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: