The last two upgrades have broken my audio setup.
First the options for Network Server and Network Access in paprefs were greyed out and my sinks disappeared after upgrading to bookworm. I just had to create a link to an existing file and it was working again but, it’s weird that it was needed in the first place. Pretty sure it has something to do with the change from pulseaudio to pipewire but I’m not very up to date on that subject and I just want to have my current setup to continue working.
Then yesterday I just launch a simple apt-get upgrade and after rebooting my sinks disappeared again. The network options in paprefs were still available, but changing them did nothing. I had to create the file ~/.config/pipewire/pipewire-pulse.conf.d/10-gsettings.conf and stuff it with “pulse.cmd = [ { cmd = “load-module” args = “module-gsettings” flags = [ “nofail” ] } ]” in order to have my sinks back.
I know it’s not only a Debian thing, as I can see this happening to people on Arch forums, but as Debian is supposed to be the “stable” one, I find it amusing that a simple upgrade can break your sound.
Out of curiosity why do you have your audio over the network? Just curious
Mainly because of bluetooth headphones with multiple computers. That way they are paired to only one computer and I can use them with other computers at the same time. Just right click on paprefs system tray icon, change the sink and the audio is sent somewhere else. I know it’s now possible to have bluetooth headphones that have multiple connections but it wasn’t the case a few years ago and I still find it much more useful this way.
But it’s also useful when I have my laptop near my main computer and want to use its much better speakers instead of the crappy ones on the laptop. Right click, select another sink, and that’s it.
It’s just nice to have the option to send the audio from one computer to another. It’s a shame that it’s apparently a niche thing.
@pedz
I’m on the same point. Until i had my multi connection bluetooth I worked the same way. The problem now. It does not work that nice.
I try currently to switch back. But my goal currently is using my #Kodi Mediacenter. But Kodi sems still using alsa. It was a hack to get simultaniousl y output with a bluetooth speaker. (For Radio in other rooms)
I gave up this network audio setup for Kodi.
It’ll also break all your keepassxc plugins soon. Because debian version to version compatibility is not a priority. They also don’t care if them breaking something triggers a ton of upstream bug reports, because it will only “be painful for a year”
Linus for the kernel has a strict “don’t break userspace” policy, and Debian has a “break things whenever you want, and just blame the user for not reading the news file” policy.
Is the breaking change going to happen in stable mid release cycle? Or at a major version upgrade?
IMO it doesn’t matter. People don’t read news on updates. Should they? Yes. Do they? No. Should they have to? Also no.
Linus’s point is to never blame the end user for something the kernel changed. If you want software to have widespread adoption, adding homework to simple updates isn’t how you do it. People don’t want a hobby or something to babysit, they want an operating system. Debian will go out of their way to make in-release updates go as smooth as possible, but are willing to through out entire parts of functioning packages between releases.
But this isn’t even about breaking things for the end user. This will create excessive amounts of noise on the upstream repo. People will say “Hey! My keepassxc broke!” and they report it to keepassxc, and not to Debian. To which keepassxc just has to constantly reply “no, debian changed this on you, this is not a bug.” If Debian had to deal with the fall out of their own decisions, I would say “yeah, im not sure if i agree with the decision, but oh well”… But they are increasing the workload for other teams.
It is already happening. The debian dev’s stance is “This will be painful for a year.” But it will be painful for keepassxc, NOT debian. The keepassxc devs asked them to not do this. Debian’s response might as well be “Im inflicting this pain on you, even though you’ve asked me not to. But on the plus side, it won’t hurt me at all and it will only last a year for you.” If they really have that much disdain for the project, they should just stop packaging it altogether.
So yeah, debian has the legal right to do whatever they want because keepassxc is open source. but “just because I can, and you cant legally stop me, and its extra work for you, not me” is kind of a jerk move. This is what drives FOSS contributors to get burnt out and abandon otherwise good projects.
I think what pisses me off about this is that I have zero idea what this NEWS file is or where to read it.
It’s disgusting to see the Debian dev just flagrantly ignore this. Did they even warn the KeePsssXC devs they were doing this?
Quote from one of the KeePass developers in the GitHub discussion.
@Dio9sys no, this was not communicated to us before hand, nor was there a chance to collaborate on an effective solution for both parties. There also seems to be “no going back” per Julian above. So this one way door decision is the new reality I guess. All I can say is, use Flatpak and get away from distro lock in altogether."
The changes to linux audio lately are a bit of a mess. Wireplumber completely changed their config format with 5.0 and it just stopped launching if you had v4 configs.
I do appreciate that we’re not stuck with pulseaudio anymore though so I really shouldn’t complain.
Alternatively,
