At the moment my sys-audio qube has as its audio vm “None” (and it works, at least for playing audio).
If I understand you correctly, I should not set this tag (though it seems harmless at the moment).
You most probably got hit by the bug described here: Audio qube - #73 by cumpsd
But I currently don’t have time to check that or send a pull request
There doesn’t seem to be any issue at all on my system. So I don’t know what that bug is about.
I was looking over the policy file given in the original instructions, and saw a lot of references to that tag, so I was surprised to not see the tag getting set anywhere. Apparently it doesn’t matter.
OK I do have a real issue, now.
an unnamed disposable (disp1234) will connect to sys audio so long as its dvm template has (via qvm-prefs) audiovm set to sys-audio.
A named disposable, on the other hand, will not. I set the named disposable’s audiovm, and it didn’t work, so I tried setting both its audiovm and its dvm template’s audiovm, and it still doesn’t work.
Or maybe not. Today I started my music player qube…and it wouldn’t connect to sys-audio. I tried several times, no improvement. I had to shutdown other clients (a web browser qube), restart sys-audio and then the music player qube. Then it connected. Then it turned out a named disposable I started right after that connected as well.
So there’s something “glitchy” going on but I don’t know what.
Set (/delay) those qubes to start(up) after sys-audio.
Is there a delay setting somewhere for qubes startup order that I missed, or should I write my own script?
A couple of possible answers.
In my case, the ONLY qubes set to start automatically are sys-usb and (I just added) sys-audio. So there’s not much order-dependency there. If I start (say) a browser qube, it will take care of firing up sys-net-wifi and sys-firewall-wifi. Of course that makes the browser qube slow to start the very first time because it must start the other two qubes first. On the other hand, they (and the cacher) will generally start up anyway once dom0 decides to check for updates; so if I wait ten minutes (easy if you have to do something else for a while) your browser qube will start up a lot faster.
It’s also possible to have a script start a bunch of qubes. How to do this is described here: How to have VM start on boot in the background? - General Discussion - Qubes OS Forum (qubes-os.org)
In essence you can put a script in ~/.config/autostart and it will execute when you log in. You can write qvm-start commands in it with delays and/or wait options; it won’t run until after you log in (that avoids the hassle of having to wait for autostart qubes to start up before you get a login screen). I’m probably going to set this up again, actually (for reasons having nothing to do with sys-audio).
System Tools → Session and Startup and add there any custom thing and kindly ask it to sleep until suits you, haha?
1 Like
Well, I just got rid of it.
It works, I get sound out (a huge improvement over the previoius), but it does me no good if I start a new VM and it doesn’t connect to sys-audio for whatever reason (in spite of having audiovm set to sys-audio in qvm-prefs). This behavior happens after sys-audio has been running for a while (at most a few hours).
At which point, I have to shut down every VM that is open and using it (including, very likely a browser with multiple tabs open), then restart sys-audio, then restart everything including the VM that failed to connect.
It’s not worth it.
I just made my first attempt at setting up an audiovm this week, and I was amazed how smoothly it went, I said “wow finally something works the first time!”. And it worked great… until it didn’t. My issues seem to be very similar to @SteveC .
My config
Audio VM Template: Debian 12 based, without optional packages (no pasystray, easyeffects…)
Audio VM: Just an AppVM
Otherwise I followed the guide just as-written.
Problem behaviours
- Audio clients will successfully connect once and only once, when they are started up after sys-audio.
- Restarting any qube will cause it to lose audio.
- Restarting sys-audio will cause all qubes to lose audio.
- Restarting
pipewire.servicein sys-audio will cause all qubes currently playing audio to lose audio (but qubes already connected that were not playing audio when pipewire reset will still be able to play audio) - Probably unrelated to other issues, audio starts crackling after a while of use.
I tried to fix it
I have checked journals of client qubes, sys-audio, dom0, and I don’t see anything indicating audio error when a qube has lost audio.
systemctl --user restart pipewire doesn’t help in any qube.
I have tried killing sys-audio’s qvm_start_daemon and starting it again.
I have tried the solution mentioned here: Sys-audio drops qubes on restart
Nothing has worked.
What now?
Should I bother to try with Fedora? Is there a reason to think Fedora would be different?
2 Likes
Hi, this is still a WIP and there is known issues and I don’t have enough time to try to fix it. To the best of my knowledge:
“Audio clients will successfully connect once and only once, when they are started up after sys-audio.”/“Restarting any qube will cause it to lose audio.”
In the audio template modify the file “qvm_start_daemon.py” to replace the line
events = qubesadmin.events.EventsDispatcher(args.app)
with this line
events = qubesadmin.events.EventsDispatcher(args.app, enable_cache=False)
I know you already mentioned “I have tried the solution mentioned here: Sys-audio drops qubes on restart”, but that is what worked for me to solve this specific issue
If it solve this issue, please confirm
“Probably unrelated to other issues, audio starts crackling after a while of use.”
Check this post:
If it solve this issue, please confirm
“Restarting sys-audio will cause all qubes to lose audio.” / “Restarting pipewire.service in sys-audio will cause all qubes currently playing audio to lose audio (but qubes already connected that were not playing audio when pipewire reset will still be able to play audio)”
Improvement need to be done in the source code to properly handle those cases.
“Should I bother to try with Fedora? Is there a reason to think Fedora would be different?”
Fedora could avoid this issue by default due to default config “Probably unrelated to other issues, audio starts crackling after a while of use.”, but that need to be confirmed (Audio qube - #218 by neowutran)
3 Likes
Actually that’s not the issue I had.
I have an issue where, if it’s up and running for a while (several hours or more) newly-started clients won’t work, however other clients are still connected. They don’t show up in sys-audio’s list. The only workaround so far seems to be to restart sys-audio (which usually entails restarting all of the qubes that are already using it, because they won’t reconnect to the new sys-audio).
For all I know, the change you mentioned might just do the job, or at least allow me to not have to restart other clients (though I’ll have to temporarily reset their audiovms during the restart). I’ll try it.
Could it be related to that Audio qube ("There is a maximum of ~19 qubes that can be running simultaneously without using audio (but with a audiovm configured). After that number, when a new qube is created, sys-audio will stop working. ")?
Nope. I’m nowhere near 19 qubes. Besides which, sys-audio continues to work for the qubes that were already connected to it. Its just that a newly started qube wanting to use audio doesn’t ever show up in sys-audio’s audio GUI as a source.
This works just as you said, to allow qubes to restart without losing audio. Unfortunately qubes will still lose audio in other ways. And to ever need to restart a qube to fix its audio, that makes using an audio qube not worth it to me (because some of my qubes are very time-consuming to restart).
But I am pleased to say I found a solution that is tolerable.
First of all, I recreated the template, this time basing it on fedora-40-minimal instead of Debian 12. I am hopeful working with this newer version of pipewire will be an overall better experience for me. I’ve run it for one day without audio crackling, which is long enough for me to conclude it has fixed my crackling issue.
Secondly, I discovered a way to manually reconnect qubes that have lost audio. This will help me in any case I cannot easily restart that qube:
- Find the domain ID of the qube to be connected to the audiovm. I do this with
xl listin dom0. - In sys-audio:
pacat-simple-vchan -l <id> <qube-name> - The qube should have working audio again. If not, may need to
rm /var/run/qubes/pacat.<id>in sys-audio, and then try again.
So it looks like I am running a dedicated audiovm from now on. Thank you for the guide!
1 Like
I did make the suggested change to my sys audio and start it up (and connect qubes to it).
I will try connecting some different qube to it this evening to see if I still have the issue I raised above.
It just occurred to me that what I might have been doing was shutting down a qube then restarting it later and having it not connect. I’ll try testing for that as well, and if that turns out to be what I am seeing I’ll try that reset that likeafox discovered.
I have had no glitches with sys-audio since I last posted!
helped me to have qubes who restart regain audio - prior every qube lost audio when restarting
Hi tried your guide up to bluetooth config.
Cant start sys-audio as only Audio device I can find is my Audio device Advance Micro device option. Have an AMD GPU but can’t see any audio options for it so assume this is good enough/it.
Getting error: Unable to reset PCI device 0000:03:00.1:internal error: Active 0000:03:00:0 devices on bus with 0000:03:00.1, not doing bus reset, see /var/log/libvirt/libxl/libxl-driver.log for details.
Which is just:
Libxl_pci.c:2098:do_pci_remove: Domain 2:xc_physdev_unmap_pirq irq+46: Invalid argument
libxl: libxl_domain.c:889:pvcontrol_cb: guest didn’t ackowledge control request: -9.
Has already config to default audiovm in dom0.
Another issue is I cant see blueman-manger in my list of applications, can confirm is installed.
For bluetooth to work you need to attach the bluetooth adapter to this qube.
The bluethooth adaper is most probably a USB device and should be available in the Qubes Devices widget in tray.
PCI troubleshooting | Qubes OS
Refresh the Applications list for the app qube. In the Qubes Menu for the app qube* launch the Qube Settings. Then go to the Applications tab and click “Refresh Applications”