I’ve been using Pipewire for a while, it was great because I could use my Bluetooth headset with a better audio Codec than in Pulseaudio. Unfortunately, my headset stopped working one day suddenly with Pipewire. (maybe after a dist-upgrade?) No amount of disconnecting, unbonding etc. would work. Went back to Pulseaudio as a sound server. Sad.
Neither Pulseaudio nor Pipewire remember to use by screen speakers (hdmi) as default, though. It always switches back to the internal sound card.
Really, it’s as simple as that. Pulseaudio tried to be the systemd of sound and failed succeeded pretty horribly. Even its packaging was horrible, back when it was first put into Fedora and I tried uninstalling, it threatened taking down Libreoffice and Gedit with it.
Shoddy workmanship due to how eager those devs are to push their beta testing software on Production, yeah. And honestly looking back, coming from Fedora, doesn’t surprise me.
Pipewire’s got fantastic JACK support. You can even run standard JACK control GUI’s like Carla on top of it and expect them to work just like they would on regular JACK
I do still have some problems with freewheeling. Ardour always crashes on exports when using the Jack interface, but everything works over the Pulseaudio interface. It might be an Ardour thing, but it doesn’t occur when actually running Jack. So something is actually different with Pipewire.
back when it was first put into Fedora and I tried uninstalling, it threatened taking down Libreoffice and Gedit with it.
I did this back when I was a newbie and somehow destroyed either the display server or some other part of the GUI. Sound issues have made me nervous ever since.
ALSA, Esound, OSS etc were always conflicting pre-pulseaudio. Sometimes you’d get sound, you’d always have to screw around with the sound server settings in different apps between KDE and Gnome apps, and gaming was a disaster. Even just using XMMS2 was a pain with Netscape/Firefox
It was a huge step forward, even with initial teething problems.
The only thing it didn’t solve was low latency (for music production), and that’s really the huge advantage of Pipewire. It did take a while to get there though…
In Xfree86 days, Linux wouldn’t have had a future if PulseAudio wasn’t released. It was one of those critical elements (along with Compiz, XrandR, DRI, Udev, PackageKit and Steam) which actually made Linux competitive against OSX and Windows at the time
I don’t know what universe were you living in, but I remember history vastly differently. No app I ever used ever had problems with ALSA, not even gaming. XMMS or XMMS2 (or Audacious even back then when it was kinda starting) never had issues with Firefox. Only when PA was introduced I started losing audio on various apps, losing volume control, or in a few cases apps would cease listing ALSA as a possible audio output while PA was installed.
I killed PA on my machines hard and never had any issues again, and things pretty much only improved once Pipewire arrived other than having to change one (1) configuration file, and it was properly documented.
This was back in kernel 2.2 / 2.4 days when Xfree86 still needed a configuration file
If you used DE’s like Enlightenment or multiple desktops simultaneously, it only caused more issues.
Also, you HAD to configure what sound server you were using often in many apps, and I seem to recall even needing to set a path in some cases to the dev.
Pulseaudio was only problematic when it was first released.
You may have had a good experience with sound servers back then, but for the rest of us, it was a lot of additional configuration and messing around
Xfree? Who’s talking about that? I’ve only ever had to use Xorg, and I only ever needed to touch its conf file if I needed to fiddle with the refresh rate of an external monitor. (Compared to that, its “”““modern””“” replacement Wayland doesn’t even start a full desktop session on my machine)
No, we’re talking about the crap that was PulseAudio, and how ALSA; which is unrelated to XFree, worked almost flawlessly and barely needed any configuration. Formatted my machine several times and remember there was someties a path to the dev (/dev/snd or something like that usually, I think? I sometimes see it thrown around when doing advanced stuff with stuff like mpv) but I was lucky that when I had to edit my file it was for hardware bugs and not for software things. I… think? nowadays that bug is acknowledged for either at the ALSA or the Pipewire level, haven’t delved enough to check.
Dealing with sound servers on the Linux community does feel like a rarity going-backwards kind of thing: to this day, Firefox for some weird ass-reason dropped ALSA support in favour of PulseAudio. But in Debian, the packaged Firefox versions continue to work with ALSA flawlessly - as if support never was dropped, despite the many versions and changes since. Which suggests me to think Mozilla never actually dropped support, they just flipped a switch somewhere to promote PA instead, which usually comes down to money deals. Mozilla is an expert at that kind of thing.
That’s my point. I’ve been using Linux from before xorg existed. Back in those days, things didn’t auto configure.
Sorry, we’ll agree to disagree here about sound servers…
Just because audio worked perfectly for you, I assure you, it wasn’t the case for everyone else at the time. Not everything defaulted to OSS or ALSA. So, there was often additional configuration involved.
And pulse was the only one to convince everyone to drop their sound servers and provide a way to support them all. That’s a huge accomplishment. Whilst it could be argued that ALSA had the potential to do so, maybe… But they didn’t
It was such a pity they didn’t include JACK support though, because that seriously held back the Linux Music production community (which is mostly seamless in Windows and MacOS)
No idea if that’s the case but they certainly seem to have been made with the same mentality. FOSS has for a while suffered of what I call the “Icaza pest”, trying to bring the Microsoft way of design and programming into Linux. The results and troubles this causes abound, considering eg.: the fart that has been Gnome themes since 3.x, or the Gnome posturing back in the day that “users have no right to change their settings” when modernization of Gnome-terminal, and how it’d interact with stuff like screen and dtach, were discused.
As someone who occasionally dabbles in music production on Linux, I love that Pipewire lets me run JACK and Pulseaudio apps side-by-side without having to jump through hoops.
I used to have to occasionally run this but I’d say it has been at least a couple of years since I last had to. I was a pretty early adopter of pipewire because it solved some Bluetooth issues that pulseaudio had. It has improved immensely since I first started using it.
To be fair (with pipewire*) my audio issues usually related to HDMI audio output which has been a PITA for like 20 years since the days of Xbox 360.
I started using PipeWire as soon as Arch switched the recommended default and I agree, it cleared up a lot of issues and fixed my Bluetooth headset, which was nice.
My 3.5mm issues are complicated by the scenario where I have a extension cable always plugged in but not always my headphone cable (sennheisers stock cables aren’t super long)
I just wanted to add this as a “to be fair” and there is a element of “user error” where I just haven’t put enough time in to really learn pipewire.
Well last night I resolved my problems by making sure to kill all processed owned by the greeter (as seen in my other post thanks to OP^^)
`killall -u greeter’
Now I can enjoy my Ubuntu startup sound in peace /s /volume-warning
Thank you, I added the command to my Linux Journal,
Your post motivated me to do some more trials and it ended up that my greetd greeter was locking up the audio sink.
So I made sure to add a command after the greeter exits killall -u greeter and the sink finally passed correctly to the logged in user just fine after that.
In reviewing the arch wiki some more too I’ve installed wire plumber session manager for pipewire, I am still a little confused about it’s function and relation to pipewire but maybe that has helped too?
Would love to use it, it has the incorrect channel map for my surround sound system which apparently cannot be changed like it can in pulse? After that gets sorted then sure.
my system sets the wrong bitrate for a device but I was able to configure it, you may want to browse the wireplumber wiki and see if its config options can meet your use case
That’s a good tip, it probably can but I’ll need a bit of learning to figure it out. The Linux audio situation is a hell of a learning curve sometimes.
With Wayland it was either break everything and improve, progress, and innovate over time with something actually maintainable & expandable,
Or… make x11\Xorg 2.0 and have to rewrite the entire stack yet again in only a few years.
PipeWire wins in the feature-set game, which is why it is being preferred over PulseAudio.
According to the inventor of PipeWire, this is the wrong perspective to take. PipeWire is preferred over PulseAudio as a server, clients (apps) should continue to use the PulseAudio/JACK APIs because the PipeWire API is not designed for general use (it’s designed for things like pipewire-pulse and pipewire-jack).
So the middleware stays the same but the underlying server changes? That’s an amazing strategy I wish Wayland did this instead of breaking damn near everything with it’s strange restrictions on behavior and overlays
Really? Like not letting apps draw over other apps? As far as I know Windows still allows that, so does even Mac OS. I don’t know who in the industry decided that screenshotting is a bad behaviour and needs to be removed but maybe they should find a new industry, like fast food line work for example.
Allowing any app unrestricted access to the input and output of any other app (like in X11) is a terrible security practice. It allows for trivially easy keyloggers and makes horizontal movement to other apps after the first has been exploited super easy.
Many people’s answer to this is “then just don’t run untrusted apps, duh”, but that is a bad take since that isn’t realistic for 99% of users. People run things like Discord or Spotify or games or Nvidia drivers all the time, not to mention random JavaScript on various websites, so the security model should be robust in the presence of that kind of behaviour. Otherwise everyone is just a single sandbox escape in the browser away from being fully compromised by malware installed with root privileges. Luckily we know better now than when X11 was designed and that is the reason for things like Bubblewrap (used in Flatpak for sandboxing), portals and the security model of Wayland.
And in the end: the people who decided this are the people actually willing to do the work to build and maintain the Linux desktop stack. If anyone knows what the right approach is, it’s them.
Are you comparing 40years of graphical environment stability and global use with something that has been broken for more than a decade and now all of a sudden is portrayed as secure?
I want to start applications as another user in my own environment and my own system and wayland prevents me, while x11 allows me (together with many forms of sandboxing and containerization).
I have asked this question to all pretend to be experts of wayland and I have 0 responses.
I absolutely am. Calling Wayland “something that has been broken for more than a decade” rather than “something that has been in active development for more than a decade” is also an interesting take. By that measure X.Org is “something that has been broken for almost two decades”, so let’s just not go there. And I’m not saying that Wayland magically makes everything secure. I’m saying that Wayland (or something like it) is a necessary step if we want a desktop that is secure. I have seen people propose something like nested sandboxed X servers with a single application for each as an alternative, but I think it’s probably better to actually fix the underlying problem.
That’s an interesting use case. It isn’t really anything I’ve had a need for, so I don’t know what the best way to do something like that is. If your compositor doesn’t allow it, could it perhaps be possible to run as a different user in a nested compositor, like Cage or gamescope? Also, how do you sandbox the applications X11 access? If they share the same server, then a sandboxed application can just wait for you to launch a terminal and use sudo, at which point it can inject a malicious command as root.
I don''t use systemd or logind so I don't have to worry about such magic security violations this bogus pile of crap creates. I have more control of processes and don't allow some "automated" service to be loging-in-out system users 2000 times a nanosecond as logind does.
It only happens when I want it to happen, not uncontrollably.
So I guess your question wasn’t in good faith then, but just bait so you’d have an excuse to rant about things unrelated to my answer?
The security issue that Wayland helps solve has nothing to with systemd or logind, so I’ll just ignore your tirade against them. If you don’t want to use them, then good on you.
The issue is an inherent issue with the X11 protocol. It can be worked around, but it can’t be fixed without something changing in the protocol on a fundamental level. The core premise that any client can be trusted unquestionably is broken and was broken the second browsers began running JavaScript. Not to mention all the other times most modern computers run opaque code of uncertain origins.
Keeping it simple is definitely a great basis to build a secure system upon, it just can’t stand alone because of reasons like the above.
What would js be able to do out of firejail or other such forms of containment?
I only allow js for very specific sites, and most that you can't do without I just do without. I am not that worried about security though, it is just an exercise.
I use seatd with wayland but it can be compiled without it too. My main issue is as I said, I can't just run "sudo -u user2 leafpad" for example, you say it is a security measure, I say it is an inconvenience.
The X11 connection is generally an enormous hole in such containment, but yes. Such containment definitely helps. That is why I run as many applications as possible as Flatpaks, as they employ similar countermeasures, and why they’re playing an increasingly big role in modern distros.
And it’s great that you’re risk averse and able to avoid untrusted scripts to that degree. It’s just not feasible for the general user, which is why things need to be secure even if a malicious script is mistakenly allowed to execute.
I’m not saying that that specific annoyance is a security measure. I’m saying that the whole paradigm shift that Wayland is is partially motivated by improving security. Such paradigm shifts come with paper cuts, especially in the beginning. But the rough edges are being filed down one by one. That’s not to say that Wayland is the answer for everyone yet, nor that it will ever be. There’ll always be exceptions. But for the vast majority of users it is, and it helps keep their systems safer than they are without it.
Not at all, seems like you’re reading things into it that aren’t there.
By modern distros I mean that for the newer variants of multiple large distros (Like Fedora Silverblue and its cousins, openSUSE MicroOS, etc.), even ordinary Ubuntu, Fedora and their derivatives and cousins, across the major DEs like Gnome and KDE, for all of them apps packaged like Flatpaks and Snaps have an increasingly large role.
I’m specifically not saying it’s the only way to be modern or that other approaches can’t have merit, I’m saying there is a clear trend among some of the largest players in the game.
I think it’s dangerous to put words in other peoples mouths and then argue against those imaginary statements, and I think it’s sad that you seemingly feel it’s the best way to argue for what you believe in. You can do better.
You have a very narrow perception of what a linux distribution/system should be, and that is a heavily commercial windows/macos alternative for people who deny reading.
That audience makes total crap popular!
Not even close, you’re even more off base than you were before. I mean what do you even base your ridiculous statements about my opinions and perceptions on?
Nice appeal to authority. Are you referring to a formalised security model (of which I’d love to read more, if you have a link?), or the actual clipboard on your PC?
But not all interaction is equal. Access control and granularity of permissions is something X11 is sorely lacking in, which Wayland has built in. Which is why X11 is a bad fit for common treat models and Wayland is not.
Ohh, @LainTrain said so, so it must be true! I’ll let you keep believing that while I enjoy them and watch them grow in popularity and usage, just like Wayland.
I’m referring to the actual clipboard on your PC, yes.
Don’t get me wrong ofc X is not without issues at all, but Wayland is like chopping off your arm at the elbow because you messed up some nail polish, and you arguing for it is like saying that now since you don’t have that arm anymore no one can break it, while all the other OSes watch on in horror and embarrassment as they allow all access to screen elements to any random app like god intended.
If you got malware installed it’s all over anyway. Why bother with weird screen access when you can just ransom the home partition and all personal files instead?
Without OBS, Discord, Steam, Guake, proper screenshot tools, etc. it’s not really a functional OS anymore for general use and that’s what you get with Wayland.
If Wayland fixes all the issues with it I’d happily switch, but it likely won’t since they are fundamental to it’s design and if so then the only way it will secure Linux desktops is by making no one ever use one again.
A “security” that interrupts the user or prevents them from doing their work is bad, because it incentivizes the user to skip or disable it, and the use of a Linux system already can get most of the ways to do either of those via ${packagemanager} install. Thus it’s more like security theatre.
From what I gather, the wayland model of things is so ridiculous that it can’t even provide for global hotkeys - which are, like, the guaranteed way to setup an interface the user can trust because it’ll always mean that when the user users it. I doubt wayland would even be Magic SysRq keys-compatible.
The thing with Wayland and X11 is: this couldn’t really be done because of how fundamentally broken incompatible X11 is (and there is XWayland for most clients that mostly works)
The message is still to use the PulseAudio and JACK APIs. They are proven and they work and they are fully supported.
I know some projects now use the pw-stream API directly. There are some advantages for using this API such as being lower latency than the PulseAudio API and having more features than the JACK API. The problem is that I came to realize that the stream API (and filter API) are not the ultimate APIs. I want to move to a combination of the stream and filter API for the future.
I remember a lot of people kicking up a fuss about it years ago saying it’s a mess and we should stick to PulseAudio or routing audio to ALSA, but personally for me it’s been great, far less troublesome than previous solutions, and the vast majority seem to agree.
The pain points were short-lived and now we’re reaping the benefits of having a modernised, easier to maintain, less janky system. Credit to the devs, and to the distros who pushed it.
And rightly so. There’s a reason we’re migrating away from pulse to pipewire.
For the longest time the solution to any audio issues was “just uninstall PulseAudio, and use plain ALSA”, and that usually worked. I held out for years and ran an ALSA only setup because it just worked and PulseAudio was always giving me one issue or another (audio lag, crackling, unexplained muting), until some applications started to drop ALSA support.
Then Pipewire came along, and so far it has been rock solid for me.
Both were just a pain in their own right, IMHO. My previous Focusrite interface was quite fiddly to get working with ALSA and just worked OOTB with Pulseaudio. I also don’t miss messing with ALSA/JACK at all.
Pipewire has pretty much been a drop-in replacement for me, with how it can act as a Pulseaudio backend.
Pulseaudio used features of sound cards (most prominently the hardware read pointer) that ALSA/dmix alone never used.
ALSA/dmix could allow you to get the same power savings as pulseaudio if you set the hardware ring buffer size to, say, 2 seconds.
And that would be fine of you were just playing some music, but if you were also chatting and wanting to get prompt notification sounds they would always be delayed between 0 and 2 seconds depending on where the hardware read pointer happened to be when the system tried to play a notification sound.
ALSA/dmix could also allow you to set a tiny buffer size. Then your music would play, and your notification sounds would play promptly too. But if you were just playing music your CPU would never be able to go into the lower power sleep states because it would need to wake up every centisecond to service the tiny ring buffer.
That would kill your battery life.
Pulseaudio’s (terribly named) “glitch free” audio feature was the first solution for Linux that allowed you to get power savings and low-ish latency. Your mp3 player filled up the ring buffer once every two seconds, and if a notification came in pulseaudio would look at where the hardware read pointer was, take the contents of the buffer that was just about to be read, and mix the notification sound into it, writing the newly mixed sound data to the buffer just before the sound card read it.
So, from the user’s perspective nothing interesting seemed to happen, but they get better battery life and things like notifications or game sounds work like they expect them to.
ALSA drivers would commonly advertise support for accurately and precisely reporting the position of the hardware pointer, but since nothing actually used that info before, many drivers gave incorrect results, which would only cause problems when using pulseaudio.
And then firefox broke apulse again due some sandboxing permissions, and you had to override it with some about:config flag: security.sandbox.content.write_path_whitelist
So that worked for a while and then the audio in some proton games stopped working, and that’s when I said fuck it and gave up. I’m only prepared to play the whack-a-mole game for so long, and if the solution to pulseaudio flakiness becomes even more alsa related flakiness, it’s not worth it anymore.
I remember a lot of people kicking up a fuss about it years ago saying it’s a mess
I remember the same type of discussion when PulseAudio was new, nearly 20 years ago. It’s just growing pains. I hopped on board with PulseAudio ASAP back then, and yeah, it was kind of a mess but it did what I needed, and the alternatives did not.
I don’t recall having any audio issues in recent years, either on PulseAudio OR PipeWire. But then again, I’m still not running Wayland (I plan to…soon™) and this is the first I’ve heard of issues with Flatpak (maybe I’ve been using PipeWire longer than I’ve been using Flatpak; can’t recall).
The latency is insanely low on Pipewire, which is important for rythm games like osu!, that’s why I originally switched to it. It’s also really cool how it’s compatible with all other audio backends as well.
Add comment