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

21–30 of 203 posts

Re: PipeWire: The Linux audio/video bus

#21

Post by gmueckl »

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 that are routinely brought up to block any kind of useful sound mixing and routing inside the kernel. But I think that all necessary resampling can easily be provided as part of the user space API wrapper that hands buffers off to the kernel. And the mixing can be handled in integer maths, including some postprocessing. Device specific corrections (e.g. output volume dependent equalization) can also fit into the kernel audio subsystem if so desired.

AFAIK, Windows runs part of the Audio subsystem outside the kernel, but these processes get special treatment by the scheduler to meet deadlines. And the system is built in a way that applications have no way to touch these implementation details. On Linux, the first thing audio daemons do is break the kernel provided interface and forcing applications to become aware of yet another audio API that may or may not be present.

This is just my general opinion on how the design of the Linux audio system is lacking. I am aware that it's probably not a terribly popular opinion. No need to hate me for it.

[End of rambling.]

Re: PipeWire: The Linux audio/video bus

#22

Post by jjoonathan »

phkahler wrote: post #15
freeqaz wrote: post #13

Earlier quoted context omitted.

I'm not sure I understand this. Why can't you just increase buffer sizes and write more data to them to avoid frequency of wake ups? Edit: does this help? https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ...

Low latency is a goal. From video conferencing to music recording it's very important.

Eh, just process all audio in a once-a-day batch job at 2am, it'll be great!

Re: PipeWire: The Linux audio/video bus

#23

Post by kevincox »

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…

Thanks for the datapoint. I've been following https://github.com/NixOS/nixpkgs/issues/102547 and considering trying it out for a while.

Did you just set services.pipewire.pulse.enable=true?

https://search.nixos.org/options?channel=unstable&show=servi...

My major concern is that I use PulseEffects as a key component of my setup so I'll need to check if that works well with PipeWire. But the only way to be sure is to try it!

Re: PipeWire: The Linux audio/video bus

#24

Post by sp1rit »

I'm currently trying pipewire on openSUSE Tumbleweed. I'm very impressed with it so far.

(After realizing it was broken, because I didn't have the pipewire-alsa package installed => No audio devices) The pulse drop-in worked flawlessly out of the box. I'd had some isssues with the jack drop-in libraries tho. (metalic voice, basically not useable) To fix this, I had to change the sample rate in /etc/pipewire/pipewire.cfg from the default 48000 to 44100.

Re: PipeWire: The Linux audio/video bus

#25

Post by kevincox »

phkahler wrote: post #14
londons_explore wrote: post #7

Without audio buffer rewinding, you're going to have to suffer random stutters and jumpiness every time your system comes under heavy load. Your system does an NMI because you plugged the power cable in? Your audio will glitch. It will also mean you won't be able to sit with an idle CPU while playing music - the audio daemon will have to wake up to reload buffers multiple times per second, killing battery life unacce…

One of the goals is low latency realtime audio to take the place of Jack. That requires small buffers frequently filled. I doubt that's very power hungry on today's systems. Also handling other tasks can be pushed on another core. So far it works better for me than Pulse did.

It did talk about being adaptive. So if you are just listening to music it should be able to use large buffers. However if you switch to something with low-latency demands it can start using smaller buffers.

My main concern is that without rewriting how can you handle pressing play or pause? Sure, that music isn't realtime and can use large buffers but if I start playing something else, or stop the music I still want it to be responsive which may require remixing.

Re: PipeWire: The Linux audio/video bus

#26

Post by jancsika »

phkahler wrote: post #15
freeqaz wrote: post #13

Earlier quoted context omitted.

I'm not sure I understand this. Why can't you just increase buffer sizes and write more data to them to avoid frequency of wake ups? Edit: does this help? https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ...

Low latency is a goal. From video conferencing to music recording it's very important.

Except that professional music recording is a domain in which low latency always trumps power consumption. So if a system based on such a tradeoff fails even once due to complexity of buffer rewinding or whatever, the professional musician loses.

Hell, Jack could be re-implemented as power-hungry, ridiculous blockchain tech and if it resulted in round-trip latency / 2 professional musicians would still use it.

Edit: added "complexity of" for clarification

Re: PipeWire: The Linux audio/video bus

#28

Post by tinco »

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…

I only read this article, so I'm still fuzzy on the exact technical details, but couldn't a system like pipewire eventually be adopted into the kernel after it has proven itself adequate? Or is that not a thing the kernel does?

Re: PipeWire: The Linux audio/video bus

#30

Post by bitbang »

superluserdo wrote: post #16

Does anyone know if pipewire has its own audio protocol for applications, as well as taking the place of JACK and Pulse? Or will future applications still just decide whether to talk to "JACK" or "Pulseaudio"? (Both actually being pipewire)

It does. The support for Pulse and JACK APIs is to ease adoption.
Post reply on HN