PulseAudio 15 Lands mSBC Codec Support To Enable Bluetooth Wideband Speech

[phoronix]

Phoronix: PulseAudio 15 Lands mSBC Codec Support To Enable Bluetooth Wideband Speech

While PipeWire is being increasingly looked at by desktop Linux distributions as the future of audio/video stream handling on the Linux desktop, aside from Fedora most Linux distributions are so far being cautious in replacing PulseAudio. In any event, PulseAudio is showing no signs of letting up and continues seeing new feature development...

https://www.phoronix.com/scan.php?page=news_item&px=PulseAudio-mSBC-Wideband

[s_j_newbury]

Until PipeWire comes up with support for multi-user/multi-seat and networked audio, it's just a partial solution. PulseAudio is just better at some things and is more versatile which is probably why it still gets new features like this first. I get the impression PipeWire, as a project, doesn't want to end with the same level of complexity as Pulse, or indeed Jack. It wants to be a drop-in-replacement for the "typical use-case".

It's similar to the situation with Meson, where a low complexity, minimal build system ends up becoming increasingly complex to deal with all the same corner cases every other build system encountered. Pragmatism won out with Meson. If PipeWire sticks to this policy it will never be able to fully displace PulseAudio and Jack, or if it does, many users will find their use-cases unsupported.

[zdzichu]

By the way, Pipewire support mSBC since 0.3.21. But it's disabled by default (can be enabled in /etc/pipewire/media-session.d/bluez-monitor.conf).

[wertigon]

Until PipeWire comes up with support for multi-user/multi-seat and networked audio, it's just a partial solution.

What is preventing anyone from implementing a Network daemon that speaks Sound-over-IP on one end and PipeWire on the other end? With up-and-coming mainline support for PREEMPT_RT, this could even be implemented at sub milliseconds latency.

As for multi-user pipes, Pipewire already supports that for both Audio and Video. Any pipe may have zero or more inputs and zero or more outputs. So the infrastructure is there, now all we need are a few GUI applications. E.g. the boring but necessary polishing part.

[mppix]

Until PipeWire comes up with support for multi-user/multi-seat and networked audio, it's just a partial solution. PulseAudio is just better at some things and is more versatile which is probably why it still gets new features like this first. I get the impression PipeWire, as a project, doesn't want to end with the same level of complexity as Pulse, or indeed Jack. It wants to be a drop-in-replacement for the "typical use-case".

Pretty much everything said here is the exact opposite!
Pipewire supports multiuser (P.A. is not).
I cannot think about a usecase where P.A. is more versatile.
Pipewire already supports this and is quite ahead with supporting high-quality bluetooth codecs.
Pipewire has a much better architecture that allows it to cover much more functionality (low-latency multi-user sound and video) while keeping it manageable.

P.A. is a subpar audio solution compared to Win and Mac. For example you cannot run 192k audio with real-time scheduling without making the machine stuttering... Pipewire makes Linux audio competitive if not more advanced.

[caligula]

P.A. is a subpar audio solution compared to Win and Mac. For example you cannot run 192k audio with real-time scheduling without making the machine stuttering... Pipewire makes Linux audio competitive if not more advanced.

How is this relevant for ordinary desktop users? You can't hear anything past 22 kHz.

[HD7950]

I don't understand why there is such a rush to bury Pulseaudio. The truth is Pipewire can´t replace Jack or Pulseaudio at this moment.
Maybe in the future, but not for now. Even Pipeware devs admit it: https://gitlab.freedesktop.org/pipew...commend-to-use

I have never had any problems with Pulseaudio in the last decade, so I plan to continue using it until Pipewire has been proven to be a real improvement without losing any Pulseaudio feature.

[Sloth]

I don't understand why there is such a rush to bury Pulseaudio. The truth is Pipewire can´t replace Jack or Pulseaudio at this moment.
Maybe in the future, but not for now. Even Pipeware devs admit it: https://gitlab.freedesktop.org/pipew...commend-to-use

I have never had any problems with Pulseaudio in the last decade, so I plan to continue using it until Pipewire has been proven to be a real improvement without losing any Pulseaudio feature.

Same here. I love the idea of Pipewire but every time I switch to it, I end up switching back due to instability. Some day it will replace PA, for sure. Not yet - so mSBC support in PA is a big deal.

[schmidtbag]

I don't understand why there is such a rush to bury Pulseaudio. The truth is Pipewire can´t replace Jack or Pulseaudio at this moment.
Maybe in the future, but not for now. Even Pipeware devs admit it: https://gitlab.freedesktop.org/pipew...commend-to-use

I have never had any problems with Pulseaudio in the last decade, so I plan to continue using it until Pipewire has been proven to be a real improvement without losing any Pulseaudio feature.

PA had a rough launch and a strong association with Ubuntu and Lennart Poettering, which triggered a lot of people to hate and remain hateful of it. People tend to cling to first impressions.
Depending on your configuration, it can be pretty heavy on CPU usage, which I would say is the worst thing about it today, because that affects everyone. There are plenty of other issues with PA but they only affect specific configurations.

[AnAccount]

How is this relevant for ordinary desktop users? You can't hear anything past 22 kHz.

Not relevant for a desktop user listening to music, since as you say, we cannot hear that. But, for a general audio architecture it is important to handle audio above what we can hear, since there are pro users mixing audio. And Pipewire is also aiming for the pro users with its Jack support.