Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PipeWire: The Linux audio/video bus

lwn.net

Post reply on HN
Print view View original

41–50 of 203 posts

Re: PipeWire: The Linux audio/video bus

#41

Post by FooBarWidget »

onli wrote: post #19

> including the raw Linux ALSA sound API, which typically allows only one application to access the sound card. If the raw in that sentence is not meant as a special qualifier and this is meant as a statement about ALSA in general, this is wrong. I recently read up on this to confirm my memory was right when reading a similar statement. In fact, ALSA had just a very short period where typically only one application a…

> In fact, ALSA had just a very short period where typically only one application accessed the sound card.

For some definition of 'short period'. Software mixing via dmix worked for me, but at the time I've heard for years that dmix was broken for many other people. Not sure whether things are better nowadays.

The breakage seems to be caused by hardware bugs. Various authors had the stance that they refuse, on principle, to work around hardware bugs. I guess I understand the technical purism, but as a user that attitude was unhelpful: there was no way to get sound working other than to ditch your laptop, and hope that the next one doesn't have hardware bugs. In practice, it seems a large number of hardware had bugs. Are things better nowadays?

Re: PipeWire: The Linux audio/video bus

#42

Post by iovrthoughtthis »

onli wrote: post #19

> including the raw Linux ALSA sound API, which typically allows only one application to access the sound card. If the raw in that sentence is not meant as a special qualifier and this is meant as a statement about ALSA in general, this is wrong. I recently read up on this to confirm my memory was right when reading a similar statement. In fact, ALSA had just a very short period where typically only one application a…

Dmix seems rather limited and doesn't come automatically setup for all audio devices. [1]

[1]: https://alsa.opensrc.org/Dmix

Re: PipeWire: The Linux audio/video bus

#43

Post by gmueckl »

the8472 wrote: post #35
gmueckl wrote: post #21

Nah, another audio daemon is not what Linux needs IMO. This should be merged into the kernel, especially since process isolation is one of the stated goals. Running hard realtime stuff in a user space that is designed to not provide useful guarantees related to hard deadlines is brave, but ultimately somewhat foolish. I know that there are arguments against having high quality audio rate resampling inside the kernel…

> AFAIK, Windows runs part of the Audio subsystem outside the kernel, but these processes get special treatment by the scheduler to meet deadlines. Assigning deadline-based scheduling priorities to the pipewire daemon wouldn't do the same job?

Isn't the deadline realtime scheduler optional? How many distros do actually ship it in their default kernels? I honestly didn't manage to keep track of this.

Re: PipeWire: The Linux audio/video bus

#44

Post by spijdar »

cyborgx7 wrote: post #29

This is giving me xkcd "Standards" vibes. https://xkcd.com/927/ I hope I'm wrong. There is a lot of potential to do better in that realm.

Given that it supports ALSA, PulseAudio, and JACK, I don't think it's like that at all. Assuming it works, it subsists of both all the other standards and a new one, keeping existing applications working with its own new advantages.

Re: PipeWire: The Linux audio/video bus

#45

Post by fulafel »

onli wrote: post #19

> including the raw Linux ALSA sound API, which typically allows only one application to access the sound card. If the raw in that sentence is not meant as a special qualifier and this is meant as a statement about ALSA in general, this is wrong. I recently read up on this to confirm my memory was right when reading a similar statement. In fact, ALSA had just a very short period where typically only one application a…

Trivia: Some sound cards (eg pas16) showed up as multiple devices using OSS too and you could output pcm audio to 2 simultaneously.

Re: PipeWire: The Linux audio/video bus

#46

Post by cycloptic »

gmueckl wrote: post #21

Nah, another audio daemon is not what Linux needs IMO. This should be merged into the kernel, especially since process isolation is one of the stated goals. Running hard realtime stuff in a user space that is designed to not provide useful guarantees related to hard deadlines is brave, but ultimately somewhat foolish. I know that there are arguments against having high quality audio rate resampling inside the kernel…

Putting this into the kernel won't solve anything that isn't already solved with things like the Linux realtime patch. The way this works is that the applications themselves need to have a realtime thread to fill their buffer, and the audio daemon has to be able to schedule them at the right time, so it's not just the daemon that needs to have special treatment from the scheduler.

Also keep in mind that these audio daemons work as an IPC to route sound between applications and over the network, not just to audio hardware. Even if you put a new API in the kernel that did the graph processing and routing there, you would still likely need a daemon for all the other things.

Re: PipeWire: The Linux audio/video bus

#47

Post by mwcampbell »

onli wrote: post #19

> including the raw Linux ALSA sound API, which typically allows only one application to access the sound card. If the raw in that sentence is not meant as a special qualifier and this is meant as a statement about ALSA in general, this is wrong. I recently read up on this to confirm my memory was right when reading a similar statement. In fact, ALSA had just a very short period where typically only one application a…

Another point against dmix: I would be surprised if it worked with sandboxes like Flatpak. That may be another reason why major desktop-oriented distros like Fedora Workstation haven't embraced it.

Re: PipeWire: The Linux audio/video bus

#48

Post by tylerjl »

> Second, D-Bus was replaced as the IPC protocol. Instead, a native fully asynchronous protocol that was inspired by Wayland — without the XML serialization part — was implemented over Unix-domain sockets. Taymans wanted a protocol that is simple and hard-realtime safe.

I'm surprised to read this; I was under the impression that D-Bus was the de jure path forward for interprocess communication like this. That's not to say I'm disappointed - the simpler, Unix-y style of domain sockets sounds much more in the style of what I hope for in a Linux service. I've written a little bit of D-Bus code and it always felt very ceremonial as opposed to "send bytes to this path".

Are there any discussions somewhere about this s/D-Bus/domain socket/ trend, which the article implies is a broader movement given Wayland's similar decision as well?

Re: PipeWire: The Linux audio/video bus

#49

Post by mxmilkb »

_0ffh wrote: post #36
pta2002 wrote: post #5

Just tried it on NixOS, had no idea it was so fleshed out already! Thought it'd be full of bugs but was pleasantly surprised, it just worked. No issues with compatibility, extremely low latency and has JACK and PulseAudio shims, so everything works out of the box, including pro audio stuff like Reaper and Ardour. And thanks to the JACK shim I can patch around the outputs with qjackctl. This is compared to JACK, which…

>This is compared to JACK, which I never managed to properly combine with PulseAudio. Yeah making PulseAudio play nice with JACK seems to be tricky. Over time I configured it in four different environments (different Linux Distributions and/or Versions) and for each of them I had to do things (at least slightly) differently to get them to work.

Using JACK apps to route between PulseAudio apps under PipeWire is magic, as is being able to turn on external DACs after login and still be able to use them with JACK apps without restarting any software. Also PulseAudio not randomly switching to the wrong sample rate when I open pavucontrol is a blessing. (And it's so easy to setup, at least on Arch Linux.).

I have come to describe PW as like a superset of JACK and PulseAudio.

Also to note, #pipewire is very active on freenode, and wtay regularly drops into #lad.

Re: PipeWire: The Linux audio/video bus

#50

Post by war1025 »

onli wrote: post #19

> including the raw Linux ALSA sound API, which typically allows only one application to access the sound card. If the raw in that sentence is not meant as a special qualifier and this is meant as a statement about ALSA in general, this is wrong. I recently read up on this to confirm my memory was right when reading a similar statement. In fact, ALSA had just a very short period where typically only one application a…

My understanding back in the mid 2000s when I first got into Linux was that OSS only let you play one audio stream at once, and the whole point of ALSA was that it let multiple applications access the sound card.

I guess I could be remembering that wrong, but I know I was listening to multiple audio streams long before PulseAudio came onto the scene.

Post reply on HN