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

51–60 of 203 posts

Re: PipeWire: The Linux audio/video bus

#51

Post by onli »

FooBarWidget wrote: post #41
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 princi…

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

Re: PipeWire: The Linux audio/video bus

#52

Post by declnz »

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

I found it tricky at first but got a mostly smooth setup on two machines now with wide variety of uses.

Definitely for day-to-day use the Ubuntu Studio app has actually been the most helpful (direct control / visibility into the Jack PA bridging is great), or a combo of qjackctl and Carla for more Audio-focused stuff.

Re: PipeWire: The Linux audio/video bus

#53

Post by onli »

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.

Jop, definitely. I still remember this clearly because I was into gaming. And while I could play some games with wine, Counter-Strike iirc, my friends used Teamspeak. Teamspeak had a proprietary linux version, but it used OSS. Before `aoss` became a thing (or maybe just known to me) there was no way of having teamspeak on and ingame sound, and teamspeak needed to be started before the game.

Only using alsa fixed this, mumble I think then became a good alternative for a short while.

Re: PipeWire: The Linux audio/video bus

#54

Post by mxmilkb »

kevincox wrote: post #23
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 t…

I didn't get to try it under PipeWire on my Arch laptop before that died the other day, but a friend had said PulseEffects is no longer such a massive CPU hog under PipeWire, so much so that they run it all the time now.

Re: PipeWire: The Linux audio/video bus

#55

Post by bluGill »

fulafel wrote: post #45
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.

Trivia, FreeBSD looked at Alsa and decided they were using a rewrite as an excuse to not fix OSS and so they dug in and fixed OSS so it worked.

Re: PipeWire: The Linux audio/video bus

#56

Post by declnz »

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.

Yeah but: the key differentiator to me is supplying drop-in replacements / adapters for all the other standards from early on in the process. This is why it isn't #927 I say...

Re: PipeWire: The Linux audio/video bus

#57

Post by jancsika »

I'm just thinking of all the disparate use cases for Linux audio, all the disparate types of inputs/outputs, complex device types involved, etc.

But then I think about pro-audio:

* gotta go fast

* devices don't suddenly appear and disappear after boot

* hey Paul Davis-- isn't the current consensus that people just wanna run a single pro-audio software environment and run anything else they need as plugins within that environment? (As opposed to running a bazillion different applications and gluing them together with Jack?)

So for pro-audio, rather than dev'ing more generic solutions to rule all the generic solutions (and hoping pro-audio still fits one of the generic-inside-generic nestings), wouldn't time be better spent creating a dead simple round-trip audio latency test GUI (and/or API), picking a reference distro, testing various alsa configurations to measure which one is most reliable at the lowest latency, and publishing the results?

Perhaps start with most popular high-end devices, then work your way down from there...

Or has someone done this already?

Re: PipeWire: The Linux audio/video bus

#58

Post by onli »

iovrthoughtthis wrote: post #42
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

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?

Re: PipeWire: The Linux audio/video bus

#59

Post by gens »

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…

Resampling in userspace and then sending it to the kernel is how it already works.. in ALSA. The only real problem with how ALSA does things is that you can't just switch the output (for example sound card to hdmi) for a running stream. PA solves this by basically being a network package router (bus, switch, "sound daemon", however you want to call it). PulseVideo^H PipeWire, from little i cared to look, is basically the same thing.

Another problem with ALSA, as well as PA, is that you can't change the device settings (sampling rate, bitrate, buffer size and shape) without basically restarting all audio. (note: you can't reeealy do it anyway as multiple programs could want different rates, buffers, and such)

In my opinion, the proper way to do audio would be to do it in the kernel and to have one (just one) daemon that controls the state of the system. That would require resampling in the kernel for almost all audio hardware. Resampling is not a problem really. Yes, resampling should be fixed-point, and not just because the kernel doesn't want floating point math in it. Controlling volume is a cheap multiply(or divide), mixing streams is just an addition (bout with saturation, ofc).

Special cases are one program streaming to another (ala JACK), and stuff like bluetooth or audio over the network. Those should be in userspace, for the most part. Oh, and studio hardware, as they often have special hardware switches, DSP-s, or whatever.

Sincerely; I doubt i could do it (and even if i could, nobody would care and the Fedoras would say "no, we are doing what ~we~ want"). So i gave up a long while ago. And i doubt anybody else would fight up that hill to do it properly. Half-assed solutions usually prevail, especially if presented as full-ass (as most don't know better).

PS Video is a series of bitmaps, just as audio is a series of samples. They are already in memory (system or gpu). Treating either of them as a networking problem is the wrong way of thinking, IMO. Only thing that matters is timing.

PPS And transparency. A user should always easily be able to see when a stream is being resampled, where it is going, etc, etc. And should be able to change anything relating to that stream, and to the hardware, in flight via a GUI.

Post reply on HN