PipeWire Audio Backend Comes To QEMU

[cb88]

So this is basically an alternative for -audiodev pa?

PulseAudio... alternative to? I've been specifically avoiding PulseAudio for a decade.

[mb_q]

This Fedora background looks really nice.

Yeah, this was my personal favourite; it got replaced by those ugly balloons and never really recovered https://web.archive.org/web/20230422...iki/Wallpapers

[Quackdoc]

Looks like the github issues were hidden away once they moved to Gitlab. This was something I asked about back in 2017, so it's awesome to see

https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2

Still unclear if it allows supporting more than stereo (which the pulseaudio backend was constrained to), but if not I guess for Linux guests you'd just workaround that via network to the host instead of an audio device using this backend?

I haven't tried audio via QEMU for a long time, but if this pipewire backend better handles avoiding the audio issues I mentioned in the feature request, that'd be fantastic

looks like 8 channels after a quick grep, might be wrong though, I plan on compiling and testing it within the week

EDIT: 8 being 7.1 since one LFE
EDIT2: with how pipewire works, you could easily just create a couple of sinks, multiple audio devices, and conjoin them using a wireplumber config if you need more channels

[polarathene]

Looks like the github issues were hidden away once they moved to Gitlab. This was something I asked about back in 2017, so it's awesome to see

https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2

Still unclear if it allows supporting more than stereo (which the pulseaudio backend was constrained to), but if not I guess for Linux guests you'd just workaround that via network to the host instead of an audio device using this backend?

I haven't tried audio via QEMU for a long time, but if this pipewire backend better handles avoiding the audio issues I mentioned in the feature request, that'd be fantastic

[Quackdoc]

wonder if this lets us run ableton live inside a vm with lower latency. since current solutions are something like 8-12ms

I'm not sure if it will, I don't see why there would be any lower latency then using jack for instance. you might be able to use a shared memory device or socket and pump audio over that?

[hax0r]

I'm waiting for wayband, a new wayland inspired protocol for audio, DBM (Direct Buffer Manager) should allow for perfect buffer samples at 48KHz (similarly how wayland locks you to 60fps), then swayband, a fork of sway, will implement the new wayband protocol, all desktop apps will need to be re-written for audio to work, there should be an uredirected buffer output for compositors (that support it) to allow up to 192KHz (to enjoy what you paid for) though the samples won't be pitch perfect. After the inception of wayband, it should take ~15 years for necessary extensions to be added to wayband protocol (to support features like bluetooth audio) or S/PDIF that the authors of wayband did not deem necessary during development of the protocol specifications.

[dreamcat4]

but getting back to the question why we need native pipewire protocol implemented on the client apps. well to transition to a 'pull' architecture. the way the buffering and interrupts / dma works we want the final endpoint hardware consuming the audio to be calling the shots. so it should be the one to ask for the next buffer originating from the output side calling backwards through the whole audio chain. and only pipewire can do this pull architecture on linux right? so thats the whole point of it. at least this has been my understanding ever since learning about pipewire. of what is the actual benefit to have a native pipewire chain without translation to any other protocol (pulse, jack).

now perhaps not everybody is going to notice much for their specific low quality and pretty ignorant use cases. but that does not mean there aren't tangible benefits for others. in particular mostly for realtime audio processing at lowest possible latencies, overheads and jitter. and 2nd to that a full pull architecture might also make for a more power efficient audio pipeline on a mobile platform (for laptops, phones and tablets). to give a bit longer battery run times. for the millions of us who just want to put spotify on all the time

now clearly, in the year 2023 there is very little expectation to deprecate all this pulse audio stuff floating about. however pipewire as a core infrastructure platform should be intended to last maybe 20 years right? so then in the long term, by 2040 or some timelines far out. then native pipewire protocol should eventually become the majority case for most popular client side apps. just by the general nature of the way a lot of our software ends up getting replaced over time. probably not even that long really tbh.

[dreamcat4]

wonder if this lets us run ableton live inside a vm with lower latency. since current solutions are something like 8-12ms

[mether]

I don't see the need for a new client library for applications. Besides, what kind of features do regular apps need? If we are talking about music applications (DAWs, etc.), then there is libjack for that, which pipewire can do as well.

One of the big reasons for PipeWire is support for desktop portals for sandboxed applications.

[Monsterovich]

If PipeWire is merely acting in PulseAudio compatibility mode, it can only support the features that PulseAudio already has. Using PipeWire directly instead allows applications to take advantage of any current and future PipeWire native features instead of being limited by the features exposed by baseline compatibility shims.

I don't see the need for a new client library for applications. Besides, what kind of features do regular apps need? If we are talking about music applications (DAWs, etc.), then there is libjack for that, which pipewire can do as well.