New audio server Pipewire coming to next version of Ubuntu The next release of Ubuntu, version 22.10 and codenamed Kinetic Kudu, will switch audio servers to the relatively new PipeWire. Don't panic. As J M Barrie said: "All of this has happened before, and it will all happen again." Fedora switched to PipeWire in version 34, over a year ago now. Users who aren't pro-level creators or …
No, it won't. The fixes for that would come from the BlueZ project,
I'm wrong, the two need to interact in a meaningful way for this to work. So its a combination of features from BlueZ, and from the sound daemon (pipewire or pulseaudio) are required for bluetooth audio/headsets to function properly.
Maybe grab a Ubuntu 22.10 daily build and try it out on a usb stick.
-> I'm wrong, the two need to interact in a meaningful way for this to work.
Why is this so in the Linux world? How many Bluetooth devices and sound devices are there for Windows?
I turn on my BT headset and it works on Mac and Windows. On Linux I have to wait until two groups of people knock their heads together in a meaningful way?
I mean, it's very likely the case behind the scenes in Windows too. Microsoft has Bluetooth devs and audio devs.
You just don't get to see inside the sausage factory in that case.
Apple and Microsoft also have a hell of a lot more resources to fund paid developers on these things, and the makers of the hardware generally don't care whether it works on Linux and so don't work to fix it if it doesn't, leaving it all up to the maintainers of the stacks to figure out the problems and fix them.
I hear you on that. My BlueTooth headset did 'Just Work' on Void Linux, then an update borked it a few months back. All the Googling on the subject claimed that it never has worked, and gave the sort of setup destructions that give us a bad name. Since the first claim was clearly not true I'm not inclined to even try to follow their advice.
You get a thumbs up for using Void Linux. Why does Void Linux garner a thumbs up from your humble VoiceOfTruth? Because, as it states on the web site Void Linux is 'Not a fork!'. That's right, it's not just another Ubu clone with some new awesome desktop wallpaper.
I may be given to mild hyperbole when I refer to tens of thousands of Linux distros. Void Linux goes one further than me! 'Unlike trillions of other existing distros, Void is not a modification of an existing distribution.' There you have it. Trillions of other distros.
I found switching to Fedora with pipewire cured the bluetooth issues I had. I did try installing pipewire on Mint first but it was just as bad as it had been with pulseaudio.
Previously I also used to temporarily disable pulseaudio to play music through a usb dac into the hi-fi - pulseaudio gets in the way of good audio quality at the best of times.
In most distros, yes. The pulseaudio team have been rejecting patches to make it work for at least a year now. You can dig up the issues with discussion on their bug tracker. Switching to pipewire magically fixes this... It allows the bluez additions to work.
>The pulseaudio team have been rejecting patches to make it work for at least a year now.
Well, yes. It works perfectly on Poettering's setup. Therefore: 1) there is no problem with PulseAudio, 2) the patches are not needed, WONTFIX, and 3) he can go off to work his unique magic on some other aspect of Linux.
Disk partitioning, for example. Why is that not handled by systemd? It would make sense, right? Right?
(Please note icon. Tongue firmly in cheek.)
systemd-repart grows and adds partitions to a partition table, based on the configuration files described in repart.d(5).
If invoked with no arguments, it operates on the block device backing the root file system partition of the running OS, thus growing and adding partitions of the booted OS image itself. If --image= is used it will operate on the specified image file. When called in the "initrd" it operates on the block device backing /sysroot/ instead, i.e. on the block device the system will soon transition into. The systemd-repart.service service is generally run at boot in the initial RAM disk, in order to augment the partition table of the OS before its partitions are mounted. systemd-repart (mostly) operates in a purely incremental mode: it only grows existing and adds new partitions; it does not shrink, delete or move existing partitions. The service is intended to be run on every boot, but when it detects that the partition table already matches the installed repart.d/*.conf configuration files, it executes no operation.
Oh, lord. Really?
Reality once again out-ridicules parody.
I grasped around for some aspect of the modern computing process that there was no way systemd would have infected. Something as far away from its nominal initial purpose - init scripts - as possible. Something that has been settled and a done-deal on the Linux platform for a long time, with a mature toolset that just works. Partitioning! Yes! That's it! I'll use that as my hyperbole example!
Bugger.
If their sound card is working, that is. Prepare to be downvoted.
-> Seriously, this stuff should not even be an issue in the 21st century.
OS/2 had working sound 30 years ago. It didn't have many drivers, but it covered most of the top selling sound cards at the time. I had an Aztech Labs sound card back then, it came with a floppy with drivers.
So why is this still an issue in the 21st century? Becoz.
I agree,
I reluctantly used Pulseaudio as I was having a lot of problems with the sound on a new install and because it's the recommended service to use on the distro I use.
When I went to play one of my games the noise was horrendous, hissing, howling and so on. I quickly knocked Pulseaudio on the head and reverted to using ALSA. The sound returned to normal and I seemed to have more control over the server with alsamixer.
As Pulseaudio runs on top of ALSA what's the point of Pulseaudio? Or is it another of Poettering's attempts to have total control of your system.
I can't wait to try pipewire. Things can only get better.
Now where have I heard that phrase before? :-)
Like the article says, if you don't have any sound daemon then you can only play one thing at a time. Anything else that tries to play audio will get an error when it tries to open the sound device if something else is currently playing, which is not what most users expect.
When I went to play one of my games the noise was horrendous, hissing, howling and so on. I quickly knocked Pulseaudio on the head and reverted to using ALSA. The sound returned to normal and I seemed to have more control over the server with alsamixer.
The howling/hissing was probably because your computer was overloaded by playing the game, and the sound server could no longer keep up. This is one of the problems of pulseaudio, it requires a lot of cpu.
If you're using ALSA, you're no longer using a sound server, but playing a game is a situation where you might want exclusive audio, so switching to ALSA might be a good compromise, even if pipewire does use less CPU.
Linux for your grandmother, the play. Two parts, Grandma and her grandson Bob.
Grandma: Hello Bob. Can you help me with this Linux thing?
Bob: Sure thing. What's the problem?
Grandma: The sound doesn't work properly. Mabel's laptop has Windows and it just works.
Bob: Which sound daemon are you using, Grandma?
Grandma: Oh, what's that Bob?
Bob: Without it you can only play one sound at a time.
Grandma: It's all so confusing, Bob.
Bob: There's OSS and ALSA and PulseAudio and JACK, UncleTomCobley's emulated triangle sounds. We can always try PipeWire.
Grandma: What's PipeWire? It doesn't give me a clue what it does.
Bob: It's named like that so you couldn't possibly guess. It's a sound thing.
Grandma: Why didn't they call it something like 'sound system version 2 or 20'?
Bob: That would be too easy.
Coming up next, Linux for your greatgrandmother.
"Like the article says, if you don't have any sound daemon then you can only play one thing at a time. Anything else that tries to play audio will get an error when it tries to open the sound device if something else is currently playing, which is not what most users expect."
And yet, I have pulseaudio and pipewire both on my "taboo - never install" blacklist (OpenSuse Leap), and have no problem listening to a music stream while watching 2 simultaneous videos, each with their own volume control, working perfectly. Maybe I'm holding it wrong..
the article is wrong.
You don't need a sounddaemon for mixing. Alsa has that functionality built in and enabled by default. For many years. It was called dmix back in the day when you had to enable it in asoundrc - and is still called that way if you want to disable it.
Unlike pulseaudio it does not butcher the sound quality or ruin your fps.
I switched to Fedora with Pipewire a year ago and it's solved both the bluetooth codec issues I was having and the denigrated sound quality I used to get when using the laptop as a sound source for the hi-fi. It sounds pretty much as good as going straight to ALSA. As far as I know, Poettering has nothing to do with Pipewire...
The thing that annoys me most about PulseAudio is just how unnecessary it seems to be. Improving ALSA's documentation would have obviated most of its functionality, while the rest could have been added in to ALSA itself if it was deemed necessary. Poettering (for it was he!) decided that he'd rather stake his claim on the audio daemon space and write a wrapper for ALSA that "fixed" the problems (chief being that ALSA didn't work the way he decided it should work), rather than contributing to existing software and improving it.
(Given subsequent behaviour, writing wrappers for other things so he can stake control of the space seems to be his MO. I'm just surprised he hasn't written a wrapper for etc and called it "systemd-registryd". Maybe I shouldn't give him ideas...)
PipeWire isn't a poettering special, but it feels like the devs have the same motivation: a wrapper around existing systems to "fix" them, rather than just working with the existing software to implement those fixes. Maybe I'm just jumping at shadows this time, because audio on Linux definitely suffers from the constant churn of new sound servers and wrappers and such. It'd be nice if someone fixed the underlying software instead.
I was debating whether to also rant about PipeWire pulling in video as well as audio to the same service, but I can kind of see the point there. It's all signal processing when you get down to it.
Some things are not "fixable", and I doubt that you could "fix" the problems in PulseAudio without replacing it, especially as Pipewire handles video as well as audio.
Ubuntu 22.10 is a non-LTS release so most users won't see Pipewire until a decision is made to put it into an actual LTS release and that hasn't happened yet.
The same thing happened with Wayland (replacement for X). It was tried out in non-LTS releases but most users didn't see it until it was judged good enough for an LTS release.
This is why there are LTS and non-LTS releases. If you want bleeding edge, then use non-LTS. If you just want to use your computer for daily work, then use LTS. Simples.
> Ubuntu 22.10 is a non-LTS release so most users won't see Pipewire until a decision is made to put it into an actual LTS release and that hasn't happened yet...
> This is why there are LTS and non-LTS releases...
Sadly I recall PulseAudio being shoved directly into an LTS release (Hardy?). That said it's caused me very little direct grief in the last decade or so, and its functionality has been very useful for some odd projects I've worked on.
I do recognise there are still plenty of issues with PA, and I've met others who have had audio issues to this day. Fortunately PipeWire has proven a reliable fix for a such issues, so I look forward to it taking PA's place.
I remember PulseAudio first appearing in Hardy.
I understood how sound hung together in Dapper, and was getting good sound out of my Thinkpad (probably a T23 at the time) using ALSA.
I upgraded to Hardy, and sound went to pot. Firstly, not all the programs would actually recognize PulseAudio, but that could have been because they were still using either OSS or ESD, and needed to be told to use the ALSA interface. This was probably because I did an in-place upgrade, and many of my defaults would have been carried across from Dapper in the config files in my home directory. If I had done a clean install, and started my home directory from scratch, I may have missed that bullet.
But for years, I had a problem. If I freshly booted the system, sound worked fine. If I suspended it, and then resumed it (I think it was both suspend and hibernate), something happened to the re-sample rate somewhere, and the pitch of the audio rose about a semi-tone, and I then got regular half-second gaps, because the data was being taken from one of the buffers faster than it was filling.
Even though I spent hours researching the problem, I never got to the bottom if it, and the bug I filed was closed as unreproducable, because nobody else reported it. I think the problem persisted on a T30, and eventually went away when I moved to a T43, but that could also have been fixed by a later Ubuntu release (I tended to do distro-upgrades between LTS releases at the same time as I upgrade my hardware).
This actually highlighted a problem with keeping and migrating my home directory between upgrades. I still do it, (although I've started archiving many of the .something directories, and starting those from scratch), but on my daily driver, I'm astounded to now find I have files I created in the last centurary hiding in corners of my home directory from way back when I first started using a laptop as my daily use system.
The hardware's changed, but the system's stayed the same!
Yes, ALSA can do much more than the basics, but the documentation is skimpy and obscure, and the configuration syntax is peculiar.
I've fiddled with it a bit in the past. You can create virtual sound devices and mix them down to a real device, solving the "can't play two sources at once" problem. Or, the other way round, you can "tee" a single source into multiple sound cards. You can even route sound to a capture file if you want to steal streamed content.
Of course, the process always involves searching the internet for someone else's solution to a similar problem, and then guessing what changes are needed to make it do what you want.
This post has been deleted by its author
This...just isn't really right, though.
We had sound servers before PA, as the article notes. GNOME used esd and KDE used arts. Every distribution shipped them. This wasn't Lennart's idea. PA was written, and generally adopted, in an attempt to replace and improve on both. It was generally considered to have achieved this, which is why the desktops and distributions adopted it.
People who encounter bugs with sound servers generally get frustrated at their existence, but people trying to build desktops and applications that play sound are unanimous in the opinion that a sound server is necessary to do it properly. If neither PA nor Pipewire existed, another one would promptly be invented, GNOME and KDE would adopt it, and all distributions would ship it.
Sound servers don't exist because nobody is "fixing the underlying software", really. They're just a layer of abstraction that's generally agreed to be useful. There's nothing exactly "broken" about ALSA, but it is by design written at a pretty low level of abstraction, and app and desktop developers don't like writing to that level.
I don't think it's really true to say that "audio on Linux definitely suffers from the constant churn of new sound servers", either. I'd say on the whole it *benefits* from constant churn in sound servers. PA wasn't perfect but it was, on the whole, an improvement on esd/arts. Pipewire isn't perfect but so far it seems to be, on the whole, an improvement on PA. If neither PA nor Pipewire had been written, and we were still using esd and arts, would things be better? I question that.
In some extreme cases PulseAudio has been known to potentially cause hearing damage for headphone users, because of the "flat-volumes" feature... So it's not just only a nuisance, it can actually cause a health and safety issue and if it happens in the workplace, that's really really really bad. Thus potentially subjecting the employer to liability. See the PulseAudio article on Wikipedia and specifically the "Problems during adoption phase" section.
It comes down to if your PC has a high-powered headphone amplifier built in. Mine does, but others only output relatively low level signals on the headphone jack.
Lennart Poettering likes to say "I'll break your audio", but he could actually break your hearing too, if you are unlucky and have a misconfigured system. That was not a problem we had with ALSA.
> Before PulseAudio became the standard, many distros used ESD, the Enlightened Sound Daemon, which came out of the Enlightenment project, best known for its desktop.
Also ARTS (KDE).
> You can play, or record, sound without a sound server, but if you don't have one, the current program that is playing sound owns the audio device: it has complete and exclusive control over it, meaning that the operating system can't mix sources.
Not really true. Long before PulseAudio came along, nearly all sound cards allowed multiple simultaneous streams. Those that didn't were supported by "dmix" in ALSA, which is automatically loaded for the default sound device these days, though sadly not for additional devices (like the USB headset you plugged-in), still requiring a bit of a configuration mess.
PulseAudio is a culprit here, too. It locks the sound device (even while nothing is being played) so those apps trying to output to ALSA can't access the sound card. PipeWire is supposed to fix all this, natively compatible with applications outputting to ALSA and PulseAudio, simultaneously. Here's hoping.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
