Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PipeWire: A year in review and a look ahead

collabora.com

Post reply on HN
Print view View original

111–120 of 125 posts

Re: PipeWire: A year in review and a look ahead

#111

Post by coffeecat »

TD-Linux wrote: post #107
jancsika wrote: post #90

Earlier quoted context omitted.

The PA docs claim that buffer rewinding is used to achieve low-latency updates to a high-latency stream. E.g., user wants to change volume now on some music that has a 2 second buffer. Seems like a common use case. How does Pipewire deal with this? Also-- links to the audio driver bug reports, please! Also-- links to info on the hardware bugs, please! I believe you, I just want to read about them.

>How does Pipewire deal with this? It doesn't, it sets a much shorter max buffer length so that the latency is always acceptable. This does mean that in theory, with an otherwise totally idle system, PipeWire can't be quite as low power as PA.

So if Windows/MacOS/Jack all lack support for buffer rewinding without noticeable latency, does that imply that Pulse encourages the use of abnormally large buffers compared to what all other audio systems use?

Re: PipeWire: A year in review and a look ahead

#112

Post by t00 »

I switched to PipeWire few months back on Manjaro and apart from a problem with packages when switching, there is one issue which bothers me slightly - Bluetooth headphones delay. I tried all codecs on my QC35-II, 3 different BT 4 and 5 dongles and the delay is unbearable, rougly 500ms, kills CS:GO experience. On a headphone jack PipeWire is great, audio is clean without any glitches. Just this bluetooth...

Re: PipeWire: A year in review and a look ahead

#113

Post by jboynyc »

chockchocschoir wrote: post #21
jboynyc wrote: post #2

I recently made the switch in NixOS and found it pretty painless. Can't get my mic to work in Firefox though, and the other day I was looking through the manual trying to figure out how to use my HDMI screen's speakers rather than the built-in one and couldn't find the right incantation. Sounds like such rough corner cases will be a thing of the past soon. Congrats to the dev team!

I wonder how your setup is different than mine. I also switched to Pipewire (some months ago) and I'm using NixOS and Arch Linux, and on both I could just change the audio output to my speakers on my monitors (via HDMI) with the usual device switch, same as before with just PulseAudio. Everything works perfectly.

I must admit I simply didn't realize the pulseaudio commands would still work. I figured they wouldn't because they were no longer installed after disabling pulseaudio and switching to pipewire. That's why I was trying to make things work with the pw-* commands and failing.

Re: PipeWire: A year in review and a look ahead

#114

Post by skrtskrt »

t00 wrote: post #112

I switched to PipeWire few months back on Manjaro and apart from a problem with packages when switching, there is one issue which bothers me slightly - Bluetooth headphones delay. I tried all codecs on my QC35-II, 3 different BT 4 and 5 dongles and the delay is unbearable, rougly 500ms, kills CS:GO experience. On a headphone jack PipeWire is great, audio is clean without any glitches. Just this bluetooth...

No delay on Fedora 35 with all defaults

Re: PipeWire: A year in review and a look ahead

#115

Post by bentcorner »

kirenida wrote: post #30

Is anybody here using pipewire to stream to a different machine on the same network? I currently use Pulseaudio to send audio from my laptop to a raspberry (with a DAC hat) connected to my hifi, but it turns out it's a pretty niche use case. So I'm looking for anybody with a similar use case who has upgraded from PA to PW and can talk about the experience.

Just in case anyone wants to do something similar between Windows boxes, NDI and Voicemeeter both do this pretty well. Voicemeeter has more features but audio quality can be hard to get right and setup can be convoluted. NDI is very very easy to configure but doesn't have as many options.

I do this "into" a RDP session in a VM on the same machine (because RDP audio is really really bad) and both of the above tools worked really well for me.

Re: PipeWire: A year in review and a look ahead

#116

Post by smasher164 »

Arnavion wrote: post #104
smasher164 wrote: post #67

Big fan of PipeWire, although I wish the tooling could work directly with PipeWire, instead of going through pactl. It's there, it's just not user-friendly. I ended up writing a tool for changing volume/muting that directly uses pw-cli: https://github.com/smasher164/pw-volume .

You can also munge the pw-dump output with jq, instead of needing something to be compiled. pw-dump | jq ' ( .[] | select(.type == "PipeWire:Interface:Metadata") | (.metadata // [])[] | select(.key == "default.audio.sink") | .value.name ) as $default_sink_node_name | .[] | select(.info.props["node.name"] == $default_sink_node_name) as $default_sink_node | . '

Yes. This is how I did it initially, before rewriting it using serde. However, as I mention here (https://www.reddit.com/r/swaywm/comments/sks343/comment/hvn3...), shell with jq was too slow -- particularly if you're holding down the volume key.

Re: PipeWire: A year in review and a look ahead

#117

Post by aftbit »

t00 wrote: post #112

I switched to PipeWire few months back on Manjaro and apart from a problem with packages when switching, there is one issue which bothers me slightly - Bluetooth headphones delay. I tried all codecs on my QC35-II, 3 different BT 4 and 5 dongles and the delay is unbearable, rougly 500ms, kills CS:GO experience. On a headphone jack PipeWire is great, audio is clean without any glitches. Just this bluetooth...

I've also experienced this on Arch Linux, in the form of a variable delay to my bluetooth speaker under pipewire but not pulseaudio. I also noticed a lot more general bluetooth flakiness. I have not characterized the issue nearly as thoroughly as you have. Instead I ran a wire to the other side of my office and installed some DIY speakers, which rendered the problem moot. Regardless, I've always had issues getting bluetooth to work reliably, especially on linux.

Re: PipeWire: A year in review and a look ahead

#118

Post by Arnavion »

yjftsjthsd-h wrote: post #110
Arnavion wrote: post #95

Earlier quoted context omitted.

I forward the pulseaudio socket (pipewire-pulse, to be precise) over ssh and it works fine.

Could you share the command to do that? I've seen `foo | ssh bar`; is it just `source | ssh 'cat >/path/to/pipe'`?

    ssh -R /run/user/1000/pulse/native:/run/user/1000/pulse/native remote_host ...
assuming the SSH client is the one with the audio device and remote_host is the one that wants to play audio. If it's the other way around then replace -R with -L.

Re: PipeWire: A year in review and a look ahead

#119

Post by Arnavion »

smasher164 wrote: post #116
Arnavion wrote: post #104

Earlier quoted context omitted.

You can also munge the pw-dump output with jq, instead of needing something to be compiled. pw-dump | jq ' ( .[] | select(.type == "PipeWire:Interface:Metadata") | (.metadata // [])[] | select(.key == "default.audio.sink") | .value.name ) as $default_sink_node_name | .[] | select(.info.props["node.name"] == $default_sink_node_name) as $default_sink_node | . '

Yes. This is how I did it initially, before rewriting it using serde. However, as I mention here ( https://www.reddit.com/r/swaywm/comments/sks343/comment/hvn3... ), shell with jq was too slow -- particularly if you're holding down the volume key.

Ah, good to know. I didn't think it would be noticeably slow, especially given it still has to spawn `pw-dump` and `pw-cli`. But I guess `pw-dump` outputs so much that speeding up just the JSON munging is still worth it.

BTW, you may consider using `Cow` instead of `&'a str` for the deserialized fields. For JSON strings that have escapes, serde can't deserialize them into a `&'a str`, so the whole deserialization will fail. `Cow` still works with `#[serde(borrow)]` in that strings that can be deserialized in-place will be the `Borrowed(&'a str)` variant, and only strings that can't will be `Owned(String)` (there's a special borrow-specific deserializer of Cow inside serde to achieve this).

Re: PipeWire: A year in review and a look ahead

#120

Post by WhyNotHugo »

smasher164 wrote: post #67

Big fan of PipeWire, although I wish the tooling could work directly with PipeWire, instead of going through pactl. It's there, it's just not user-friendly. I ended up writing a tool for changing volume/muting that directly uses pw-cli: https://github.com/smasher164/pw-volume .

I agree that tooling is still quite raw (e.g.: the Rust bindings don't expose the muted states or volume of anything), but developer documentation is even worse.

There doesn't seem to be ANY public documentation on the pipewire API protocol. There's just docs for the C bindings, but lack of protocol documentation is a bit worrying, since none of us can write tools that talk to the server. A LOT of documentation pages are literally empty (just a title an nothing else). This includes the documentation for the native protocol, in case you wanted to write your own client: https://docs.pipewire.org/page_module_protocol_native.html

Apparently, reverse engineering the client/server implementations is the way to go right now.

Post reply on HN