Pipewire, media-session, wireplumber multiple USB devices problem

mikebutash · 2024-05-04 21:31:44

At some point over the past year or two since moving to pipewire from pulse, I noticed my usb speakerphone stopped working after an upgrade, and it took me a good while to narrow down to why. The errors were reported by several folks in different places without clear answer or solutions, but finally found someone mention to use the "api.alsa.headroom" fix mentioned in the arch pipewire wiki 5.1.14, but didn't match my errors and didn't even realize this was the root of the problem being multiple streams in the first place vs "multiple devices". It took me probably a year of living without being able to work using Zoom or other conferencing services directly instead calling in with that legacy telephony technology until I found in a form someone that linked that to my direct condition and errors.

Make that even worse that recently an upgrade reverted this out of nowhere, and I had to figure out and remember what the fix was after 8-12mo after I fixed it last time.

This was not terribly easy to troubleshoot or diagnose, and imagine this is probably quite common that folks would use built-in sound devices along with USB devices like speakerphones, USB headsets, etc as well. I would ask why this isn't setup by default to increase the headroom if this is so finicky vs outright breaking anyone that does have multiple sound devices.

Is there any downside to increasing the headroom buffer per the wiki for everyone to avoid this for those of us not intimately familiar with debugging audio devices like this? It seems doing so would save a LOT of unnecessary strife and hassle.

5.4.14: Audio cutting out when multiple streams start playing
/etc/wireplumber/main.lua.d/50-alsa-config.lua (or ~/.config/wireplumber/main.lua.d/50-alsa-config.lua)

apply_properties = {
    ["api.alsa.headroom"] = 1024,
},

V1del · 2024-05-04 21:38:11

The downside of doing this for "everyone" is increased latency because you're filling up more buffers than potentially necessary. I also have multiple audio devices and multiple USB audio devices and have none of these issues with the default headroom, so this will be a "your hardware" problem. If you keep the file in /etc or ~/.config then this shouldn't break automatically in any case (outside of the config format change in wireplumber 0.5 which hopefully isn't going to happen again in a while)

mikebutash · 2024-05-04 23:19:03

While I understand the concept of buffer bloat, I first hand experienced this and have to imagine I'm not the only one as I found tons of the same reported problems, and very few good answers until I lucked out finding someone correlating the broken pipe errors to the headroom buffer sizing.

My sound setup isn't anything exotic, two enabled devices, one TI PCM2902 usb device for output only, and a Jabra Speak 510 speakerphone in duplex stereo, both I've literally used for 10+ years across before I even used arch, through pulseaudio to pipewire, and have never seen this problem. Even more so, it worked originally for a time in arch with pipewire, and only broke with an update until I found this as a fix. Since it took me 6 months or more to find a solution, I never did link it back to when or what triggered it, but presuming some update to PW and/or media-session.

I *did* add this into the /etc per the recommended snippet the first time, and this got nuked with the last upgrade a week or two ago, having to uncomment/add that bit back to apply_properties. Problem was I had to spend a few days re-troubleshooting to figure out what I fixed prior and where having not taken any notes the first time, I added it back, and added the ~/.config part as well for good measure.

If someone is *that* concerned with latency, I'd presume they're setting up RT modes anyways, but for general usability by average humans, this seems counterproductive to break potentially a good chunk of users for the sake of latency only self-proclaimed audiophiles would notice or care about, and certainly they wouldn't be messing with a jabra speakerphone if so. Just searching the symptoms I had, there were plenty of people in the "me too's" out there, and it's sort of ugly when it does break and unclear why. For instance, I noticed because playing a youtube video in firefox with both devices connected will cause it to hang the video playback, which is what triggered me to realize my fix was undone with the last pacman -Syu. If I disable the Jabra output, but leave the input enabled, it works again, but enabling the output on both the pcm2902 and jabra, videos hang, and I start getting broken pipe notices in syslog.

This time I made sure to save the config needed to fix if/when arch packages undo it again, but I'd rather see a bit more buffer added to avoid this for everyone else this can/has happened to, or perhaps a more elegant solution to add buffer as needed when it does crap the system out vs ambiguous breakage.

I figured I'd post this in case some other poor bastard runs into this too, but would be nice to see a better way to avoid this too.

V1del · 2024-05-04 23:30:30

The Arch packages don't undo anything you're adding to /etc in terms of wireplumber config ... it was an upstream config format change that mandated all your configs getting updated and wireplumber logs would have told you so. And keeping on top of stuff like this is somewhat part of the DIY "contract" you're signing up for when using Arch.

Generally speaking people that don't have issues are not going to speak up, so changing a default for a vocal minority that might have troubles is likely to make a difference for the silent majority.

Enabling simultaneous output of different sinks is already quite a niche usecase that will mandate a bigger headroom in most cases, so you've already customized something in a way most people aren't going to do.

At the end of the day this is a config option you can configure for your usecase, blaming Arch for upstream breakage isn't really generally useful.

In any case, if you want to reach the packagers to suggest such a change, your best bet is opening up a feature request against the wireplumber package presenting your arguments on the gitlab.

Last edited by V1del (2024-05-04 23:34:13)

mikebutash · 2024-05-04 23:59:30

It's not so much about assigning blame as it is trying to prevent arch users from running into the same problem, but I agree this is more a pipewire issue likely than anything, and was my next stop.

I would argue running two sound devices is hardly *niche*, as almost any large business, particularly in a windoze world, will use a usb sound device right along with whatever built-in audio device they have as well for conferencing function. Who ever uses built-in speaker/mic on a laptop for a conference call? Someone should never have to delve into obscure sound daemon configurations just to plug in a second usb speaker occasionally. It's not arch's fault, but a small thing would/could prevent larger chaos with broken sound for folks.

Just my two cents, and yes, I'll see about an issue for the core pipewire bits as well.

V1del · 2024-05-05 00:04:44

Maybe I misread, you're using those "normally" not with synchronized simultaneous output? That should generally not be that dependant on multiple devices, but if you have some device that incorrectly configures the buffer this could have an effect on the entire ALSA stack, but that would be more of a pipewire issue.

Again, you can't generalize "multiple devices likely to run into problems here" I actively use my integrated card as well as an USB headset and I don't experience issues. This is likely quite specific to your HW/driver combination.

mikebutash · 2024-05-05 00:45:22

Yes sir, no synchronization in any way, really I never use them both even at the same time. The PCM2902 I use its toslink out to my 5.1 system (just in stereo, no 5.1 or like, again nothing fancy), which is never in use when I'm on a zoom call or like to my jabra.

I would imagine if both perhaps were jamming a (far too small) buffer, but I can't imagine this would exceed any sort of rational default buffer sizing, still that's something between alsa and pipewire and don't get into the weeds that much to know why. It made a bit more sense once fixed realizing "ahh, I need to add buffer for 1+1", but this seems entirely counterproductive if everyone had to go config file hacking just to add a second speaker not even to be used simultaneously or in any otherwise crafty fashion.

Arch Linux

#1 2024-05-04 21:31:44

Pipewire, media-session, wireplumber multiple USB devices problem

#2 2024-05-04 21:38:11

Re: Pipewire, media-session, wireplumber multiple USB devices problem

#3 2024-05-04 23:19:03

Re: Pipewire, media-session, wireplumber multiple USB devices problem

#4 2024-05-04 23:30:30

Re: Pipewire, media-session, wireplumber multiple USB devices problem

#5 2024-05-04 23:59:30

Re: Pipewire, media-session, wireplumber multiple USB devices problem

#6 2024-05-05 00:04:44

Re: Pipewire, media-session, wireplumber multiple USB devices problem

#7 2024-05-05 00:45:22

Re: Pipewire, media-session, wireplumber multiple USB devices problem

Board footer