Arch Linux

PutridPete

Member

Registered: 2021-10-25

Posts: 21

[SOLVED] No sound in guest with Virt-Manager after Pipewire update

So today I launched one of my VMs using Virt-Manager, which contains Linux Mint 20.3. While it was booting, it froze my whole system for a few seconds (host and guest). Afterwards I was able to resume logging to my VM, but then I had no sound within it. In contrast, my Arch system sound worked normally. I decided to dig around a little and after checking for errors in the logfiles, I found the following:

Jun 11 14:48:07 archie pipewire[939]: pw.node: (alsa_output.usb-Razer_Razer_USB_Sound_Card_00000000-00.analog-stereo-55) suspended -> error (Start error: Invalid argument)

Seaching online for this output didn't produce any significant info, but since all issues started after updating pipewire, I decided to downgrade pipewire, pipewire-alsa, pipewire-pulse, and lib32-pipewire from 1:0.3.52-1 to 1:0.3.51-1. The issue was fixed immediately. For now, I've added them to IgnorePkg. I'd like to know if there's any way I can properly troubleshoot this. Thanks in advance for any help.S

Last edited by PutridPete (2022-06-24 17:50:19)

PutridPete

Member

Registered: 2021-10-25

Posts: 21

Re: [SOLVED] No sound in guest with Virt-Manager after Pipewire update

So if anybody else is having the same issue, I found a fix (well, kind of) that works for me every time. Before opening Virt-Manager, I change my audio device configuration using pavucontrol to "Pro Audio" and then change it back to what I had. No idea why that makes it work, but it does. Sometimes the virtual machine will freeze for a few seconds after turning it off, but no other issues that I can detect. Anyway, I'm marking this as solved for now.

Edit: Seems like there is something funky going on right now with pipewire and python based programs or programs that contain python scripts, as both OpenShot and Kodi are also affected by this issue. After digging around some, I found that the problem is also present in Chromium/Electron apps, and the user found the same temporary fix for them as I did. For now, I'm going back to my previous temporary solution of downgrading Pipewire to 1:0.3.51-1.

Edit2: The issue has now been correctly identified. It started when in version 0.3.52 of pipewire a change was introduced that allows 44100 sample rates along with 48000, which caused many applications to misbehave. For now you can downgrade pipewire to 1:0.3.51-1 (and make sure to reboot your box, just restarting the appropriate pipewire sockets and services doesn't get rid of the problem) and sit tight until a next version, or if you need the latest version of pipewire right now you can switch it and it's components to the git version available through the AUR. Those packages pull directly from the master branch, which reverted the problematic commit.

Last edited by PutridPete (2022-06-25 23:37:21)