PipeWire: The Linux audio/video bus • Hacker News Board

Re: PipeWire: The Linux audio/video bus

#131

Post by bitwize » Wed, Mar 03, 2021, 8:51 PM UTC

zajio1am wrote: post #84

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.

Maybe you haven't read Havoc Pennington's posts on why dbus was designed the way it was and the problems it solves. Start here: https://news.ycombinator.com/item?id=8649459

Dbus is about the simplest approach that solves the issues that need addressing.

Re: PipeWire: The Linux audio/video bus

#132

Post by Lucretia9 » Wed, Mar 03, 2021, 8:56 PM UTC

chenxiaolong wrote: post #10

I've been trying out the latest master builds of pipewire recently and have been pretty impressed with it: * My bluetooth headset can now use the HFP profile with the mSBC codec (16 kHz sample rate) instead of the terrible CVSD codec (8 kHz sample rate) with the basic HSP profile. * Higher quality A2DP stereo codecs, like LDAC, also work. * AVDTP 1.3 delay reporting works (!!) to delay the video for perfect A/V sync.…

Is that X11 or Wayland?

Re: PipeWire: The Linux audio/video bus

#133

Post by viraptor » Wed, Mar 03, 2021, 8:58 PM UTC

pta2002 wrote: post #126

Nullabillity wrote: post #118

Earlier quoted context omitted.

You can do that in Pulse, by using null sinks and monitor sources.

I see what you mean, still a lot more complicated than just dragging a "wire" in qjackctl though.

https://github.com/futpib/pagraphcontrol

It's not super polished, but you can do similar wire dragging here.

Re: PipeWire: The Linux audio/video bus

#134

Post by rav » Wed, Mar 03, 2021, 9:00 PM UTC

Lucretia9 wrote: post #132

chenxiaolong wrote: post #10

I've been trying out the latest master builds of pipewire recently and have been pretty impressed with it: * My bluetooth headset can now use the HFP profile with the mSBC codec (16 kHz sample rate) instead of the terrible CVSD codec (8 kHz sample rate) with the basic HSP profile. * Higher quality A2DP stereo codecs, like LDAC, also work. * AVDTP 1.3 delay reporting works (!!) to delay the video for perfect A/V sync.…

Is that X11 or Wayland?

I just installed Pipewire in Arch Linux running GNOME on Wayland, and I finally have working screensharing in Firefox: I can share e.g. GNOME Terminal (a Wayland-native non-Xwayland app) in a video meeting, which I wasn't able to do without Pipewire.

Re: PipeWire: The Linux audio/video bus

#135

Post by orra » Wed, Mar 03, 2021, 9:08 PM UTC

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

In the interest of balance, PulseAudio was a huge improvement for me.

I remember playing SuperTux on my laptop. After the switch to PulseAudio, the sound was flawless. Before that, on ALSA, the audio was dominated by continuous 'popping' noises—as if buffers were underrunning.

> the apparent endorsement from the JACK-developers also does not hurt.

Indeed, it seems a better UX to only require one sound daemon, instead of having to switch for pro work.

Re: PipeWire: The Linux audio/video bus

#136

Post by onli » Wed, Mar 03, 2021, 9:23 PM UTC

Delk wrote: post #119

onli wrote: post #37

Earlier quoted context omitted.

I don't remember this at all, but this might explain that. Or maybe a distribution like debian stable shipped with an outdated ALSA version, taken from the short period between release and dmix. Or just disabled dmix. Would love if someone remembered specifics. I kinda assumed people mix up Alsa and OSS or don't remember anymore what actually did and what did not work before Pulseaudio was introduced.

In the early 00's (before PulseAudio), my desktop had an old SoundBlaster Live PCI card that was pretty common around the turn of the millennium. ALSA dmix Just Worked with that one. Any other hardware I encountered required some kind of software mixing, IIRC. Not that my experience was extensive, but I got the impression that hardware or driver support for dmix wasn't that common.

> Any other hardware I encountered required some kind of software mixing, IIRC.

Yes, that was dmix :) And it fits the timeline, hardware mixing was killed off back then by soundcard vendors/microsoft, iirc.

Re: PipeWire: The Linux audio/video bus

#137

Post by chenxiaolong » Wed, Mar 03, 2021, 9:24 PM UTC

Abishek_Muthian wrote: post #105

chenxiaolong wrote: post #10

I've been trying out the latest master builds of pipewire recently and have been pretty impressed with it: * My bluetooth headset can now use the HFP profile with the mSBC codec (16 kHz sample rate) instead of the terrible CVSD codec (8 kHz sample rate) with the basic HSP profile. * Higher quality A2DP stereo codecs, like LDAC, also work. * AVDTP 1.3 delay reporting works (!!) to delay the video for perfect A/V sync.…

Would there be improvements for remote audio streaming over pulseaudio with ssh?

I'm not sure about this one. I haven't tried streaming audio over the network with either pulseaudio or pipewire.

Re: PipeWire: The Linux audio/video bus

#138

Post by chenxiaolong » Wed, Mar 03, 2021, 9:27 PM UTC

fulafel wrote: post #113

chenxiaolong wrote: post #10

I've been trying out the latest master builds of pipewire recently and have been pretty impressed with it: * My bluetooth headset can now use the HFP profile with the mSBC codec (16 kHz sample rate) instead of the terrible CVSD codec (8 kHz sample rate) with the basic HSP profile. * Higher quality A2DP stereo codecs, like LDAC, also work. * AVDTP 1.3 delay reporting works (!!) to delay the video for perfect A/V sync.…

Why would this affect bluetooth codecs?

I'm not super familiar with the pipewire internals, but I believe pipewire is the daemon responsible for talking to bluez/bluetoothd and ensuring that the audio stream is encoded with a codec that the headset supports.

For example, this is the PR that enabled mSBC support for the HFP profile: https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_req...

Re: PipeWire: The Linux audio/video bus

#139

Post by chenxiaolong » Wed, Mar 03, 2021, 9:27 PM UTC

Lucretia9 wrote: post #132

chenxiaolong wrote: post #10

I've been trying out the latest master builds of pipewire recently and have been pretty impressed with it: * My bluetooth headset can now use the HFP profile with the mSBC codec (16 kHz sample rate) instead of the terrible CVSD codec (8 kHz sample rate) with the basic HSP profile. * Higher quality A2DP stereo codecs, like LDAC, also work. * AVDTP 1.3 delay reporting works (!!) to delay the video for perfect A/V sync.…

Is that X11 or Wayland?

This was all with Wayland. I haven't tried using pipewire with X11.

Re: PipeWire: The Linux audio/video bus

#140

Post by londons_explore » Wed, Mar 03, 2021, 9:30 PM UTC

bluGill wrote: post #81

kevincox wrote: post #25

Earlier quoted context omitted.

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.

Except a typical desktop system is usually a mix of low latency and high latency audio streams. You're playing music, and you're typing on a 'clacky' virtual keyboard. The user doesn't want 100ms of lag with each finger tap till they hear the audible feedback. Yet when no typing is happening, the CPU doesn't want to be waking up 10x per second just to fill audio buffers.

The solution is to fill a 5 minute buffer with 5 minutes of your MP3 and send the CPU to sleep, and then if the user taps the keyboard, rewind that buffer, mix in the 'clack' sound effect, and then continue.