cubeb makes JACK stuck at Firefox's shutdown (and sometimes at runtime too)

[v-fox]

I've been having this glitch from the time cubeb got its first JACK code to the latest code that I've shoved into Firefox 49. It gives out xruns on Firefox's shutdown and rarely makes its HTML5 player stuck even before that. The longer Firefox session and more youtube videos played during it - the worse it is. With synchronous mode (-S) that allows lower jackd latency with risk of one client disrupting all sound output I get things like that:

20:01:37.209 redirection-to-jamin: jamin:a.master.out_L -> system:playback_1 checked.
20:01:37.218 redirection-to-jamin: jamin:a.master.out_R -> system:playback_2 checked.
20:01:37.229 redirection-to-jamin: CubebUtils:AudioStream_0_out_0 -> jamin:in_L checked.
20:01:37.239 redirection-to-jamin: CubebUtils:AudioStream_0_out_1 -> jamin:in_R checked.
20:01:37.249 redirection-to-jamin: PulseAudio JACK Sink:front-left -> jamin:in_L checked.
20:01:37.258 redirection-to-jamin: PulseAudio JACK Sink:front-right -> jamin:in_R checked.
JackPosixSemaphore::TimedWait err = Connection timed out
JackFreewheelDriver::ProcessSync: SuspendRefNum error
JackAudioDriver::ProcessGraphSync: ProcessWriteSlaves error, engine may now behave abnormally!!
JackPosixProcessSync::LockedTimedWait error usec = 5120000 err = Connection timed out
JackEngine::ClientDeactivate wait error ref = 6 name = CubebUtils
JackEngine::ClientKill ref = 6 cannot be removed from the graph !!
20:01:42.271 JACK connection graph change.
20:01:42.330 JACK active patchbay scan...
20:01:42.340 redirection-to-jamin: jamin:a.master.out_L -> system:playback_1 checked.
20:01:42.350 redirection-to-jamin: jamin:a.master.out_R -> system:playback_2 checked.
20:01:42.361 redirection-to-jamin: PulseAudio JACK Sink:front-left -> jamin:in_L checked.
20:01:42.371 redirection-to-jamin: PulseAudio JACK Sink:front-right -> jamin:in_R checked.
20:01:42.604 JACK connection change.
20:01:42.815 JACK active patchbay scan...
20:01:42.825 redirection-to-jamin: jamin:a.master.out_L -> system:playback_1 checked.
20:01:42.835 redirection-to-jamin: jamin:a.master.out_R -> system:playback_2 checked.
20:01:42.846 redirection-to-jamin: PulseAudio JACK Sink:front-left -> jamin:in_L checked.
20:01:42.856 redirection-to-jamin: PulseAudio JACK Sink:front-right -> jamin:in_R checked.
JackPosixProcessSync::LockedTimedWait error usec = 1024000 err = Connection timed out
JackEngine::ClientCloseAux wait error ref = 6
JackPosixSemaphore::TimedWait err = Connection timed out
JackAudioDriver::ProcessGraphSync: SuspendRefNum error, engine may now behave abnormally!!
20:01:47.272 XRUN callback (1).

That makes me seriously think about disabling cubeb's native JACK support for good and use PA as a compatibility shim. It seems it doesn't close its connections properly or something.

[kinetiknz]

@zamaudio Are you interested in investigating this bug report?

[zamaudio]

@v-fox Why are you using a PulseAudio JACK Sink as well as cubeb+JACK in the above? I recommend purging pulseaudio altogether when using JACK as your sound server.

[v-fox]

@v-fox Why are you using a PulseAudio JACK Sink as well as cubeb+JACK in the above? I recommend purging pulseaudio altogether when using JACK as your sound server.

So PA apps would work on my system, obviously ! The only thing I will be purging is glitchy FF JACK support. I'm certainly not going to workaround FF/cubeb deficiencies by messing with perfectly working setup where PA is launched by QJackCtl as JACK client for the main audio chip & manager for secondary chips like HDMI sound from video card or bluetooth headset.

After all, FF's media player sucks anyway. I download all I can to watch & listen with proper a player, like mpv. So if it will be slightly worse than it is because of additional compatibility layer it's not as bad as breaking entire system to accommodate its own wrong behaviour.

[zamaudio]

@v-fox I don't think there are any serious issues with the JACK backend for cubeb, but I'm happy to investigate this issue you are facing.

It needs to be clear that your PulseAudio server configuration should not be allowed to use the same sound card as the one jackd is using, or there will be problems with the two servers fighting for use of the same sound-card.

Once you have a JACK master running on one card and PulseAudio server banned from using it, (could be tricky to configure), you could try to run PA on the other sound devices and run a JACK client source/sink to tap into the other devices, but note that this part is not necessary to get JACK working correctly with FF. I recommend trying to get it working without pulse first and then add pulse functionality as a secondary route. After all, you seem interested in using JACK as your sound server, or am I mistaken? Most people who use JACK don't even touch pulseaudio. Your set up seems a little unique, and would be useful for those who still want things like bluetooth headsets etc and syncing through JACK via a PA sink, but it's definitely not a default set-up for JACK based audio configurations, and unfortunately it is very difficult for me to work out what is wrong in your case because of your complex set-up.

[v-fox]

@v-fox I don't think there are any serious issues with the JACK backend for cubeb, but I'm happy to investigate this issue you are facing.

Don't worry about my configuration. It does work correctly with FF, it's FF that doesn't work correctly with JACK. Or do you think that I use PA in FF and that's what glitching ? No, that always worked, I'm afraid. Although I have to first stop patching FF with JACK-enabled cubeb backport patches because of the lack of runtime configuration for cubeb. But there wouldn't be "CubebUtils" JACK client that way. So what PA has to do with anything then ?

PA is launched only after jackd (autospawn=no) and is incapable of getting to the main chip. And even if it wouldn't be, how FF/cubeb could influence that ? The only thing it can is to mess with jackd, which it does. If it really has anything to do with PA, then it too is entirely cubeb's fault for accessing PA after it already got to JACK. I stress-tested that configuration for months and optimized literally everything that can be, even built custom kernel packages for best realtime & IRQ reliability. You can try my old live build of openSUSE with that: JACK by default, patched FF, etc. Or just look into its configuration files.

So, please, look into what FF/cubeb does at FF's shutdown and what kind of invisible-in-qjackctl cubeb remnants there are that hang jackd. The main point for reproduction here is to keep JACK-enabled FF open for a long time, like >3 hours or even for days ! Also try opening >10 tabs (I use "Tree Style Tab" extension for proper tabs) with youtube for playing them one after each other but have some still open during the shutdown.

[Ace17]

Hi, I have a very similar issue on my system: the audio sometimes freezes and I have to restart firefox. I've been having these issue since the asynchronous JACK backend was introduced (the two years before I had been using the synchronous JACK backend without any issue). (BTW there's no pulseaudio at all on my system).

[zamaudio]

I have tried but I can't replicate this issue, can someone who believes this is an issue please run a debug build of firefox, and attach gdb to one of the child processes with gdb path/to/firefox $PID when it's hung and run thread all apply bt and provide a stack trace when the bug occurs. Please provide it here below.

[v-fox]

The tricky part is that Firefox has to run for a while (doesn't happen if you quickly open firefox, play something and close it afterwards) and, probably, has to have multiple tabs with media content open or them being previously played (i'm not sure if the key is to have media content just loaded or finished playing). After that it always happen on Firefox shutdown but, rarely, at runtime. You can see it by Firefox shutting down for tens of seconds and then JACK server reporting errors even if Cubeb client was not listed in its active connections anymore.

I don't think I'll be building JACK-enabled FF anymore until 89327f7ffede3f98fa2ecb3548ae760632514217 lands into a release or backend selection is implemented. Although, it is a small patch…

[Tele42]

G'day, I have a similar setup to @v-fox, but with my general usage of firefox, I do not encounter the HTML5 player stall, just the xrun(s) on closing firefox.

This exposes brittle behavior in the long-time unmaintained jack backend of MythTV and causes the MythTV playback to lose audio playback. Of course, the brittleness of MythTV is not the issue here, it's just a side note. I only need to have MythTV playing a video and close firefox after it has initialized a jack connection to reproduce this issue.

Please let me know if I can do any tests to help troubleshoot. Unless otherwise requested, I use self-compiled Firefox ESR, which is 52.2.0 as of this writing.

[zamaudio]

I have been using my own build of firefox with --enable-jack and have not experienced any serious issues except a couple of xruns when firefox is closed. This should be addressed in a separate issue that probably affects all audio backends when threads are terminated. Why you guys are so adamant it's something in my contributed code that I did wrong, I have no idea. Perhaps you should be grateful you can use JACK with firefox at all - I'm not paid to do this.

[zamaudio]

I think #366 could explain this.

[Ace17]

Dude, don't take it personally ; I also spent many weeks writing parts of this JACK backend, and I wasn't paid for it either.

Now, I had to stop using it, for this exact issue (this was nearly giving me heart attacks when the audio suddenly froze). I had been using it for 2-3 years.

Your commit definitely changed the observable behaviour of ... something in my audio system. Whether it's a bug in your code or not, I don't know. Or maybe, there's a bug in cubeb and your code triggers it? I don't know, I'm not critizing your work ; simply trying to have a working audio system again.

The thing I'm sure of, is that it's hard to reproduce. Within Firefox, I couldn't reproduce it everytime I wanted, it only seemed to happen at random, when many youtube video were playing and closing the tab of one of them. Then, I tried to make it happen in a more deterministic way by writing fuzzing concurrent tests (i.e every 10ms, open some audio streams, and stop some others) ... but with this tests, I was never able to make it happen even once.

[zamaudio]

Well I now know why it xruns at shutdown of firefox, cubeb_destroy() is never being called