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

81–90 of 203 posts

Re: PipeWire: The Linux audio/video bus

#81

Post by bluGill »

kevincox wrote: post #25
phkahler wrote: post #14

Earlier quoted context omitted.

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…

A 100ms delay between hitting pause and the pause happening is plenty fast for that use case. The same delay for pro audio mixing is way too long.

Re: PipeWire: The Linux audio/video bus

#82

Post by slabity »

aidenn0 wrote: post #68
slabity wrote: post #38

Earlier quoted context omitted.

I also have Pipewire running on NixOS. This is what I recommend configuring: services.pipewire = { enable = true; alsa.enable = true; alsa.support32Bit = true; jack.enable = true; pulse.enable = true; socketActivation = true; }; That allows me to run pretty much any application that uses ALSA, JACK, or PulseAudio.

That gave me "services.pipewire.alsa" does not exist on 20.09; does this require unstable?

I believe so, I am on the unstable channel.

Re: PipeWire: The Linux audio/video bus

#83

Post by dbrgn »

bluGill wrote: post #74
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.

Exactly. If you're working on a project in Ardour and want to quickly watch a video on YouTube, stopping Jack and starting PulseAudio was a bit of a pain the last time I did that.

Yes, you can configure PulseAudio as a Jack client, but the session handling is also a bit messy. (I used to have a PA -> Jack setup on my work computer just so I could use the Calf equalizer / compressor plugins for listening to music. I dropped it again after a while, because session handling and restoring wasn't always working properly. But that was around 6-7 years ago, maybe it would work better nowadays.)

Re: PipeWire: The Linux audio/video bus

#84

Post by zajio1am »

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…

That sounds great! D-bus always seemed to me like a byzantine overcomplicated design, and i was pleasantly surprised when i saw Wayland protocol with its simple design.

Re: PipeWire: The Linux audio/video bus

#85

Post by justaj »

onli wrote: post #58
iovrthoughtthis wrote: post #42

Earlier quoted context omitted.

Dmix seems rather limited and doesn't come automatically setup for all audio devices. [1] [1]: https://alsa.opensrc.org/Dmix

That's a very old wiki page with decades old workaround for decade old issues. I'm not saying you are wrong, but if you take this impression solely from that wiki page you are likely mislead. Afaik this always works and did for many years - but I might be wrong and always only lucky with all the systems where I tested it?

I think you've hit one of the most painful topics of ALSA: Its documentation.

Re: PipeWire: The Linux audio/video bus

#86

Post by hedora »

nerdponx wrote: post #80
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.

The problem with these busses is that each hand rolls its own security primitives and policies.

This sort of thing is better handled by the kernel, with filesystem device file permissions. As a bonus, you save context switching into the bus userspace process on the fast path. So, “the unix way” is simpler, faster and more secure.

Re: PipeWire: The Linux audio/video bus

#87

Post by figomore »

m45t3r wrote: post #72
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…

I’m using pipewire in NixOS unstable and it’s working very well. I know they are working in integrating new pipewire configuration with Nix configuration.

Re: PipeWire: The Linux audio/video bus

#88

Post by cycloptic »

hedora wrote: post #86
nerdponx wrote: post #80

Earlier quoted context omitted.

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.

The problem with these busses is that each hand rolls its own security primitives and policies. This sort of thing is better handled by the kernel, with filesystem device file permissions. As a bonus, you save context switching into the bus userspace process on the fast path. So, “the unix way” is simpler, faster and more secure.

That won't work here, the design of pipewire is to allow for things like a confirmation dialog appearing when an application tries to use the microphone or webcam, the application can then get temporary access to the device. That is a security policy that isn't really easy to do with filesystem device file permissions.

Re: PipeWire: The Linux audio/video bus

#89

Post by ori_b »

aidenn0 wrote: post #63
onli wrote: post #51

Earlier quoted context omitted.

> For some definition of 'short period'. According to https://alsa.opensrc.org/Dmix , enabled by default since 1.0.9rc2. https://www.alsa-project.org/wiki/Main_Page_News shows that was 2005. Alsa 1.0.1 release was 2004. So it's only short when counting from then on, project start was 1998. But https://www.linuxjournal.com/article/6735 for example called it new 2004, so I don't think it was much of a default choice be…

I had a sound card that would not work with OSS in 2002ish, so I guess define "default choice." Even though it was technically disabled by default, I had to enable it to get sound working.

> I guess define "default choice."

Default choice: The choice that is made with no user configuration.

Re: PipeWire: The Linux audio/video bus

#90

Post by cycloptic »

gmueckl wrote: post #43
the8472 wrote: post #35

Earlier quoted context omitted.

> 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.

The deadline scheduler is upstream, see "man 7 sched" for a description: https://man7.org/linux/man-pages/man7/sched.7.html

What is not upstream (yet) is the PREEMPT_RT patch which makes all kernel threads fully preemptible.

Post reply on HN