QEMU 8.1 Released With New PipeWire Audio Backend, Many CPU Improvements

[phoronix]

Phoronix: QEMU 8.1 Released With New PipeWire Audio Backend, Many CPU Improvements

QEMU 8.1 is now available as the latest feature update to this important piece of the open-source Linux virtualization stack...

https://www.phoronix.com/news/QEMU-8.1-Released

[zexelon]

This is awesome news... now if the Ubuntu qemu binaries could have the GlusterFS driver properly compiled in that would be even better!

[Mirox]

Does qemu kick in if I create a VM of type kvm to run a Linux OS in the guest VM. The host is Debian 12.

[zexelon]

Does qemu kick in if I create a VM of type kvm to run a Linux OS in the guest VM. The host is Debian 12.

On Linux KVM is an accelerator to Qemu. Its basically a para virtualization trick that works on x86_64 arch.

Short answer is yes you can run a Linux OS as guest on Linux OS host with Qemu and KVM will provide raw hardware acceleration (CPU only).

Depending on your end goals containers (ex. Docker) could be much better than a full up Qemu to say visualize a single app. If you are visualizing a ML/AI server especially with GPU assets thats where Qemu starts to shine.

[hkupty]

I know it's a bit off the main focus of this article, but has there been any comparison between a native PipeWire backend against the PulseAudio compatibility layer? Intuitively, it should be better to use the native backend over the compatibility layer, but how much so? It would be interesting to see a side-by-side comparison between PulseAudio, compatibility layer and native PipeWire...

[paulocoghi]

Does qemu kick in if I create a VM of type kvm to run a Linux OS in the guest VM. The host is Debian 12.

Depending on your end goals containers (ex. Docker) could be much better than a full up Qemu to say visualize a single app. If you are visualizing a ML/AI server especially with GPU assets thats where Qemu starts to shine.

I would strongly suggest Linux Containers (LXC) instead of both quemu/kvm and Docker when Linux is both on host and on guest. Using it on unprivileged mode, you have the security and experience of a VM, along with zero virtualization overhead.

[zexelon]

I would strongly suggest Linux Containers (LXC) instead of both quemu/kvm and Docker when Linux is both on host and on guest. Using it on unprivileged mode, you have the security and experience of a VM, along with zero virtualization overhead.

Very fair point. The only counter point is that Docker and Docker Swarm can be substantially easier to get up and running due to a much larger documentation base.

[Quackdoc]

Wow, there are a lot of goodies. some of the major ones are obviously mentioned. Honestly the stuff won't matter to a lot of people, but for some of us this is a massive update.

Multitouch on GTK and Dbus backend, this has been a painful point for us working with android often resulting to hacks,
Pipewire will also be quite helpful for latency, Just waiting for virtio-snd.
CanFD support will be neat to play with.
zoned device emulation that could be quite nifty too.
virtio-mem unplug support
9pfs proxy is gone
chardev independant input/output

riscv is is getting Zba, Zbb, and Zicond support on the tcg backend, nice for those users

Xen versions below 4.7.1 are not supported anymore.
The --meson and --sphinx-build options to configure have been removed

[Quackdoc]

I know it's a bit off the main focus of this article, but has there been any comparison between a native PipeWire backend against the PulseAudio compatibility layer? Intuitively, it should be better to use the native backend over the compatibility layer, but how much so? It would be interesting to see a side-by-side comparison between PulseAudio, compatibility layer and native PipeWire...

Ill be testing this for android sadly on bliss we only really support 44100hz and 16bit audio. Currently for our advanced configuration I recommend using the jack backend with AC97 emulated device for low latency audio and ICH9 for potentially higher quality. virtio-snd should be a quite the improvement but with AC97 quality and latency are already fine.

Pipewire should be equal to jack. but much more convenient you can see the cmdline invocation here https://docs.blissos.org/installatio...wirejack-audio. (also worth noting audio latency testing is not super easy on android, I used a loopback app which does add a bit of latency so the total round trip quoted is inflated by that app)

Keep in mind that pipwire latency only sets qemu side, not android side. I don't think pipewire vs jack will have too much of an impact but when I test it if I remeber ill reply here. so more or less take that 40ms reduction we get from jack and apply it to pipewire likely.

[mortn]

It's interesting to see how Qemu is this plethora of features, and in contrast we see Cloud Hypervisor basically doing the same as Qemu but with minimalistic approach instead with minimal emulation and even lower CPU/mem overhead, yet still it gets the job done beautifully.