I’m on R4.2 and using a disposable sys-audio based on debian-12-minimal, created using the tutorial at Audio qube, with the additional step specific to debian-12-minimal Audio qube - #429 by fb2043. I also occasionally run waydroid inside an AppVM, based on the tutorial at Waydroid template.
In general sys-audio is working fine. But it seems whenever I have waydroid running for extended periods, audio performance gets gradually worse, for all qubes. I’m not 100% confident waydroid is the reason (as it doesn’t happen instantly), it’s just a correlation I’ve noticed. Nobody else in the waydroid thread has brought it up, but I’m also not sure if anyone else tried to use waydroid with sys-audio. Since I was already using sys-audio when I started using waydroid, I don’t know if the same issues happens when dom0 is used as audiovm.
The issue affects audio from all AppVMs (even those in which waydroid wasn’t running), but to variable extents: for some AppVMs it’s hardly noticeable or at most there are some pops/crackling. For the AppVM that was running waydroid, audio eventually begins to stutter, along with the video being played if there is one, making media playback basically impossible. Other AppVMs will be somewhere in between. The degradation is progressive: it seems to keep getting worse the longer waydroid had been running. It never improves: it remains at the same level of degradation, or it gets worse. And it’s seemingly irreversible: setting default_audiovm to null and back to sys-audio, shutting down waydroid, restarting AppVMs or even restarting sys-audio (which is a disposable) leads to no improvement. The only solution I could find was rebooting the device.
The only reference on the forum to a similar problem was under R4.1, but without using sys-audio and it was reportedly being caused by Windows AppVMs (I don’t run any Windows AppVMs) Playing audio through Windows VM causes system wide audio corruptions/degradation. One comment in that thread stands out Playing audio through Windows VM causes system wide audio corruptions/degradation - #3 by brendanhoar by @brendanhoar, which I am pasting below:
I think this is mostly due to a) the pipeline from VMs through pulseaudio/pipewire allowing config changes to dom0 hardware based on source material sample rate/width changes (even from VMs) plus b) recent kernel/sound driver work creating defects that can be triggered by these types of hardware/driver changes.
I’ve found that playing any audio file in dom0 at (software) volume 0 in an infinite loop prevent the dom0 kernel/driver bug from triggering and allows audio to work, probably as this forces software blending of sources instead of hardware/driver config changes to match a single source. Of course this annoyingly uses processing power to block a defect trigger.
Apparently the kernel/driver bug doesn’t seem to trigger in bare metal Linux but only in Xen hosted Linux. It appears to be related to dma buffer creation/handling.
This sounds plausible, but the information is not referenced in any way and it doesn’t suggest a proper solution (apart from a possibly outdated kernel; mine is the standard 6.12.39 that shipped with R4.2).
I will try to use the audio file loop hack. I will also experiment with setting the audiovm pref of the AppVM in which waydroid is running to null, to see if I can protect audio in the other qubes from being degraded.
Apart from the obvious inconvenience (having to reboot the system whenever waydroid is used), I’m surprised about what looks like a lack of isolation between qubes. If the issue is, as the comment above suggested, due to hardware config changes, is there a way to reset the audio hardware without rebooting the device?
Any advice welcome.