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

71–80 of 203 posts

Re: PipeWire: The Linux audio/video bus

#71

Post by bluGill »

war1025 wrote: post #50
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.

OSS in non-free versions supported multiple sources. Linux sound guys decided that instead of fixing the free OSS they would write ALSA. They never really worked out all the bugs around mixing before pulseaudio took over.

Re: PipeWire: The Linux audio/video bus

#72

Post by m45t3r »

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 very own system did not work with Pulseaudio when I tried to switch, that was years later. I still use only ALSA because of that experience. At that time Pulseaudio was garbage, it should never have been used then. It only got acceptable later - but still has bugs and issues.

I remember the transition to PulseAudio. Initially, most things were broken, and we still had some applications that worked only with OSS so the whole audio suite in Linux was a mess. I remember that I already switched from Fedora (very broken)/Ubuntu (slightly less broken) to Arch Linux, and for sometime I kept using ALSA too.

Eventually, between switching Desktop Environments (I think Gnome already used PulseAudio by default them, while KDE was optional but also recommended(?) PA), I decided to try PulseAudio and was surprised how much better the situation was afterwards (also, OSS eventually died completely in Linux systems, so I stopped using OSS emulation afterwards).

With the time it was getting better and better until PulseAudio just worked. And getting audio output nowadays is much more complex (Bluetooth, HDMI Audio, network streaming, etc). So yeah, while I understand why PipeWire exists (and I am planning a migration after the next NixOS release that will bring multiple PipeWire changes), I am still gladly that PulseAudio was created.

Re: PipeWire: The Linux audio/video bus

#73

Post by gens »

cycloptic wrote: post #46
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 d…

It would solve the needless IPC, cache trashing, priority scheduling (since it becomes a kernel thread, instead of a userspace thread), and other busywork.

Re: PipeWire: The Linux audio/video bus

#74

Post by bluGill »

dbrgn wrote: post #4

The fact that PipeWire has the potential to replace both PulseAudio (for consumer audio) and Jack (for pro audio) with a unified solution is very exciting.

Particularly if you are on the pro audio side. Consumer audio can ignore pro-audio for the most part. However everyone on pro-audio needs to do something consumer audio once in a while, if only to run a web browser.

Re: PipeWire: The Linux audio/video bus

#75

Post by jsmith45 »

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…

But one of the goals of this is to be able to handle Video and audio together. (This enables an easier API for ensuring audio and video remain in sync with each other, which can be tricky in some scenarios when both use totally seperate APIs.)

The other main goal is to simultaneously support both pro-audio flows like JACK, and consumer flows like PulseAudio without all the headaches caused by trying to run both of those together.

Lastly PipeWire is specifically designed to support the protocols of basically all existing audio daemons. So if the new APIs provide no benefit to your program, then you might as well just ignore it, and continue to use PulseAudio APIs or JACK APIs or the ESD APIs or the ALSA APIs or ... (you get the idea).

Now you are not wrong that audio is a real time task, and that there are advantages to running part of it kernel side (especially if low latency is desired, since the main way to mitigate issues from scheduling uncertainties is to use large buffers, which is the opposite of low latency).

On the other hand, I'm not sure an API like you propose will work as needed. For example, There really are cases where sources A, B, C and D need to be output to devices W, X, Y, and Z, but with different mixes for each, some of which might need delays added, effects (like reverb, compression, application of frequency equalization curves, etc) applied, and I have not even mentioned yet that device W is not a physical device, but actually the audio feed for a video stream to be encoded and transmitted live.

Try designing something that can handle all of that kernel side. Some of it you will have no chance of running in kernel mode obviously. That typically implies that everything before it in the audio pipeline ought to get done in user mode. Otherwise the kernel mode to user mode transition has most of the scheduling concerns that a full user-space audio pipeline implementation has. For things like per output device effects that would imply basically the whole pipeline be in user mode.

The whole thing is a very thorny issue with no perfect solutions, just a whole load of different potential tradeoffs. Moving more into kernel mode may the a sensible tradeoff for some scenarios, yet for others that kernel side implementation may be unusable, and just contributing more complexity to the endless array of possible audio APIs.

Re: PipeWire: The Linux audio/video bus

#76

Post by cycloptic »

gens wrote: post #73
cycloptic wrote: post #46

Earlier quoted context omitted.

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 d…

It would solve the needless IPC, cache trashing, priority scheduling (since it becomes a kernel thread, instead of a userspace thread), and other busywork.

Would it? Linux does support realtime priority scheduling, JACK has worked this way for years. The thing is you need userspace realtime threads for because that is what the clients need to use, it's not enough to change just the mixing thread into a kernel thread.

Re: PipeWire: The Linux audio/video bus

#78

Post by squarefoot »

Does it also work with WINE and manages MIDI devices or it's audio only? From the project page on Gitlab it seems it doesn't; apologies for hijacking the thread if that's the case, but I'm out of ideas.

I'm currently looking for a last resort before reinstalling everything since probably after an apt upgrade all native Linux software kept working perfectly with all my MIDI devices while all WINE applications simply stopped detecting them, no matter the software or WINE version used. No error messages, they suddenly just disappeared from every WINE application but kept working under native Linux. Audio still works fine in WINE software, they just can't be used with MIDI devices because according to them I have none. WINE and applications reinstalls didn't work.

Re: PipeWire: The Linux audio/video bus

#79

Post by bluGill »

jancsika wrote: post #26
phkahler wrote: post #15

Earlier quoted context omitted.

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:…

In practice it can't though. You cannot do complex computation and still meet low latency as complex computation takes time which adds to latency. Also pros intend to use their computer, so something that complex leaves less CPU free for the other things they are trying to do.

in practice the only way this comes into play is pros are willing to fix their CPU frequency, while non-pros are willing to suffer slightly longer latency in exchange for their CPU scaling speed depending on how busy it is. It is "easy" to detect if CPU scaling is an allowed setting and if so increase buffer sizes to work around that.

Even for non-pros, low latency audio is important. You can detect delays in sound pretty quickly.

Re: PipeWire: The Linux audio/video bus

#80

Post by nerdponx »

tylerjl wrote: post #48

> 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 t…

I don't know of any discussions on it, but I like it. Client-server architectures seem like a Good Thing, and I'm growing to like the idea of a small handful of core "system busses" that can interoperate with each other.
Post reply on HN