Closed klandrith closed 4 years ago
QT version is unrelated, but would you mind telling me what audio backend do you use?
It narrows down the bug search by quite a lot.
PulseAudio. Thanks for the quick reply!
For how long do you have to wait in order to find this issue
I have this is the audio section of my xava config file.
method = pulse source = auto
yes, but how long did you wait for the bug to happen?
Well I mean I'm unsure of that because I never really pay attention. But I would say it happens after an hour or more of no audio activity. I recently setup a KVM Windows 10 virtual machine, and I have been switching back and forth quite a bit between it and my Linux desktop. Usually I notice the bug after I've been on the VM for awhile and switched back over to my main desktop. Audio output never has any problem between switching between the guest and host.
What audio setup are you using in your VM?
I think I know what's going on here: PulseAudio sink changes due to the VM and XAVA can't handle that.
tl;dr: QEMU likes to mess with PulseAudio
And XAVA ain't too happy about it...
Makes sense, I was suspecting as much. I'm using PulseAudio for the VM. I wish I could just pass in my whole audio device, but it is non-resettable, so I can't do that. I will have to explore other audio options for the VM. Doesn't seem to be a problem on xava's end then, really.
BTW, Great piece of software. It is absolutely awesome. But, is there any way to improve the graphical performance of xava though? It uses a lot of GPU resources (I only have a Nvidia GT1030 on my host)? I know that question is unrelated...
@klandrith It is (to some extent) XAVA's fault, but the behaviour is basically non-standard, if you get what I'm saying ;)
Just I'm not sure if applications can detect a dead source.
Also can you share your QEMU audio params, it could help a lot.
Makes sense, I was suspecting as much. I'm using PulseAudio for the VM. I wish I could just pass in my whole audio device, but it is non-resettable, so I can't do that. I will have to explore other audio options for the VM. Doesn't seem to be a problem on xava's end then, really.
BTW, Great piece of software. It is absolutely awesome. But, is there any way to improve the graphical performance of xava though? It uses a lot of GPU resources (I only have a Nvidia GT1030 on my host)? I know that question is unrelated...
Try disabling OpenGL. I've already had like 3 issues, all NVIDIA related. It speaks for itself. You'll lose shadows, unfortunately.
I gotcha.
This is all that I have in my audio section of my VM libvirt xml file when it comes to sound...
I just added an emulated sound device via the libvirt GUI. I am exploring other configurations right now. I could use scream for audio, but I'm not sure if that would suffer the same fate or not?
I'll try disabling OpenGL. I don't care for the shadows anyways as my desktop background is very dark and I can't see them anyways. lol.
Scream works well if you don't pin the CPU, then you get artifacting.
Bummer, I am pinning my CPU cores...ugh.
"sound model="ich9" address type="pci" domain="0x0000" bus="0x00" slot="0x1b" function="0x0"/ /sound"
Forgot to quote that...That's all I have in my XML file for audio.
Not the device in qemu, but how QEMU plays the audio itself.
To make it easier for you just share the entire thing, if you don't mind.
`
Sorry that's a mess, not sure how to format it to keep the indents and such..
yeah, it doesn't reveal much.....
What part of the qemu xml exactly are you looking for? Sorry for my lack of knowledge about this stuff. As I said, just got it going...My head is still spinning from the 100 or so guides I read last week, lol.
don't bother yourself with the details, it's mostly dev jargon anyway
the thing is I just need to be sure what the culprit is
For example, I booted up my KVM machine, and it works just fine now
a classical case of: "works on my machine"
Yah, I gotcha. That was a classic line in my CS programming and algorithms 1 class. lol "ran on my machine..."
also can you try the following dumb hack (if it works):
change the starting <domain>
tag into <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
before saving, also add:
<qemu:commandline>
<qemu:arg value='-audiodev'/>
<qemu:arg value='pa,id=pa1,server=/run/user/1000/pulse/native'/>
</qemu:commandline>
BEFORE the final </domain>
tag.
this is just to replicate my audio setup, to see if there's something about QEMU that messes with it
oh wait nevermind you don't have to change the tag, it's already done for you
but just add the second part
Yah, I gotcha. I tried that and I get an error in libvirt that it was unabled to connect to pulseaudio.
Error starting domain: internal error: qemu unexpectedly closed the monitor: pulseaudio: pa_context_connect() failed pulseaudio: Reason: Connection refused pulseaudio: Failed to initialize PA contextaudio: Could not init `pa' audio driver
Nevermind, figured it out, need to change my user in qemu config file. I was(am) running a diff user to access my keyboard via evdev.
boom, you just found the problem by yourself.
That means that pulseaudio runs as root (or whatever different user) then, and xava gets rejected access to audio (for obvious reasons)
should error out then, should it?
:thonk:
But there's a workaround for this, it's just not device agnostic... (developer speak for it doesn't work when you plug in an another device) Use alsa instead. It's complicated to set up, but it avoids problems like these.
Yah, I think we got it nailed down. Thanks for all the help! Now I'm just trying to get hda to work in libvirt. Libvirt is complaining that it can't find 'hda'.
Use alsa for xava?
Yes, but if you really sure about using it. It's difficult to set up.
Or instead, you can write a udev file that grants access to your keyboard using a certain group instead of a user.
I got it working now. Everything is going fine. Just started up the VM, switched monitor inputs to VM, audio cutoff, switched back, audio resumed and xava was still working. So it seems to be resolved. Thanks again for all the help, even though this didn't turn out to be an issue with xava!
If I still have an issue with xava cutting out again, I'll post back to this issue thread, but I think we've got it all figured out.
Yeah, I'm glad there are people testing out my code. Gives me motivation to work on the project.
Thanks for you input and happy visualizing (don't worry, you can always reopen this issue later on)
99-qemu-hw-users.rules.zip also here's that example udev file in case you need it @klandrith
Randomly (usually after quite a while of no audio activity) xava quits working. I have to kill it and restart it in order for it to work properly. If music is going, it will work for hours on end without problem. Here is my setup.
Manjaro KDE (all current) -Plasma 5.19.5 -Qt 5.15.1 -Kernel 5.8.11-1