Linux QEMU Win10 fizzling sound

Hey there!
I'm using KVM QEMU to run a Win10 guest on a Linux Mint host. I have a razer megalodon headset which even tho Razer has no official support for Linux, works perfectly on my host. But when I pass it through to my guest system, the sound gets a bit fizzling, especially at certain heights. I think it must be a question of correct audio driver for the headset, but I'm lost on what to use.
My QEMU script:

The command qemu-system-x86_64 -audio-help will give a list of audio drivers and several parameters. The only driver that most likely want to use are alsa and pa. Some of the common combinations are :

QEMU_AUDIO_DRV=alsa QEMU_ALSA_DAC_BUFFER_SIZE=4096 QEMU_ALSA_DAC_PERIOD_SIZE=0 qemu...
QEMU_AUDIO_DRV=alsa QEMU_AUDIO_TIMER_PERIOD=0 qemu...
QEMU_AUDIO_DRV=pa QEMU_PA_SAMPLES=128 qemu...

but you will have to test and it might to work 100%, since several sound issues depends on the system, distro, drivers, etc..

Try changing just one parameter several time to see what affect it has.

You might also try:

  • Shutdown all sound programs on the linux side (music player, web browser) that might cause interferance.
  • Since usb is cpu depended (at least some devices are very depended), try not giving all the cpu cores to the vm, try first only half of them
  • If you are desperate try creating another vm with win7 or win8 just to test the sound since I know some who had issues on some hardware in windows 10 but not on the others versions of windows. If you decide to try win7 you can also test -soundhw ac97 instead of -soundhw hda and install the latest realtek audio drivers.

Sounds like the Razer megalodon is a USB device. Try passing it into the guest as a USB device. A better solution would be to pass an entire USB controller into the guest. Anything plugged into the associated ports are treated as guest devices.

I didn't mention that because while other usb devices work great, a usb soundcard gitched heavily on my system when I tested because cpu usage of the device and from what I read on some forums I am not the only one. He also will loose the audio on the host side if this is is main audio source since he has to blacklist modules to prevent alsa/pulseaudio from claiming the device and cause all sorts of problems.

However, if he really want to use the device and he out of options it one more thing he can try.

In contrast, USB audio passthrough on my setup is flawless after some tweaks. Module blacklisting or vfio-pci should not be necessary. It is only a required procedure if the driver does not handle detaching and attaching the device (e.g. graphics drivers) but USB audio does not have this problem. The device will however be only accessible from the guest while passed through.

In some cases there are problem detaching sound devices. On my system, since kernel 4.4 the snd_hda_intel driver claims the audio hdmi component from my gtx960 and it would cause kernel tainted after shutting down the VM resulting in all sorts of problems. After I figured that, I had to set a parameter to set the parameter enable to that module to ignore that device. After that I am always cautious about some devices.

Out of curiosity, what are those tweaks that you mention for the usb audio ?

Like @mythicalcreature the only way I could resolve my sound issues (latency and noise) was to add a USB sound card, I opted for a cheap StarTech brand to test with and has worked out just fine.

http://www.newegg.com/Product/Product.aspx?Item=9SIA24G28N5155&cm_re=usb_sound_card-_-29-128-012-_-Product

Hey there! Thanks all for the help. Passing it through as an usb device only helped with the OS recognising it as megalodon and not an analog input, which lets me test it properly. The problem still exists tho, altough trying the most common audio setups nakamura mentioned helped to make it a lot better. Now I only get the strange static on very high pitch sounds.

Welp. After further testing, after more demanding tests (sc2 main menu music) my audio device went mute. I'd guess the driver crashed? This did not happen before, so now I'm reverting.

What do you mean by passing an entire USB controller through btw? Can you refer to it as a line in the parameter list please?

my experience is that there's not a way to completely fix it without passing it through completely.

I'd explain how to passthrough the whole usb controller, but i don't know off the top of my head and im lazy; I can, however tell you about the wonder of libvirt/virt-manager, which is basically a set of tools for managing vm's "apt-get install virt-manager" should get you started.

snd_hda_intel may be different. I was specifically referring to USB audio drivers for pass through.

They are actually mostly for if you're running a Linux guest with an Nvidia card. I can post them if you're interested, but I'm guessing people mostly just care about Windows guests.

There is one newish (qemu 2.5+?) feature however that may improve Windows audio, again if you're fighting Nvidia and their artifical driver limitations. There is a qemu option "hv_vendor=" that allows you to pass in a bogus vendor ID for your graphics card which is able to fool the check performed by Nvidia to detect that it is running in a VM. You still need kvm=off, but with hv_vendor= set (to blank), you should be able to use all hyper-V flags wihtout getting the code 43 error.

Enabling hv_time may result in less stuttering. I haven't tested because I currently don't run a Windows guest. As far as I know, hv_vendor is currently not implemeted in libvirt so you will need to pass it in as a qemu arg.

Did you pass a graphics card to the guest? If so it should be the same procedure.
They look like this on my box:

00:14.0 USB controller: Intel Corporation C610/X99 series chipset USB xHCI Host Controller (rev 05)
00:1a.0 USB controller: Intel Corporation C610/X99 series chipset USB Enhanced Host Controller #2 (rev 05)
00:1d.0 USB controller: Intel Corporation C610/X99 series chipset USB Enhanced Host Controller #1 (rev 05)
04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03)

It may or may not behave well though if you're passing through onboard USB. PCI USB cards are probably more likely to work, but again may depend on the controller chip that is used. As with may things pass through related, YMMV.

1 Like

The story:

I've been fiddling with my USB controllers and such. I'm generally confused about the whole topic, but a few things I've learned: my mobo has xHCI support and has several USB 3.0 ports. These ports are supposed to be faster and better, so I thought maybe if I pass the xHCI controller with the -device nec-usb-xhci \ argument line in QEMU, put the megalodon in a USB 3.0 port and also pass the megalodon as an usb device as well, maybe it'd be better. Now the guest wouldn't recognise the megalodon at all, and I saw the following error in the qemu terminal: "libusbx: error [_get_usbfs_fd] libusbx couldn't open USB device /dev/bus/usb/001/003: No such device"
I thought maybe since I passed the xHCI, QEMU couldn't get a hold of the megalodon plugged into the USB 3.0, but then after terminating the guest OS, even though I had the xHCI controller back (checked with lspci) I couldn't find the megalodon (even in lsusb it wouldn't show up). So I restarted the PC, plugged megalodon out and in several times, but nothing. I've concluded that xHCi is a drag and razer maybe doesn't really give good support for it, so I've turned the controller off all together in my BIOS settings. Now EHCI 1 and 2 should handle all my USB ports, including the 3.0 ones that now should work as 2.0 in my understanding.

The questions:

-At this point, how should I pass my controllers for the guest? (using host=ID-FROM-LSPCI gave an error, I only need to specify the type of the controller to pass it like I did with xHCI?)
-Should I pass both EHCI 1 and 2, or should I try to check which handles my megalodon (how do I do that?!)
-If I pass the controller responsible for handling it, should I also pass the megalodon as an USB device?
-Could xHCI be helpful in solving my shitty audio quality, and if so how do I make it work with megalodon properly?
-Is it safe to pass all controllers to the guest, will the host be able to get a hold of all USB devices after guest terminates?

Notes:

If you could help with the actual argument line I have to type when referring to a method (such as passing the USB controller) that would be a HUGE help, but I do appreciate any constructive comment that I may get!
Thank you all for your time and help!

Oh, and I JUST noticed that I already pass the controllers I believe. I linked my qemu script with my first post and it included uhci ehci and xhci pass-throughs. I copied my script from this website earlier and started modifying it, but I kept that part in it, that's why I wasn't aware that I was already doing it. According to my lspci I only have EHCI 1 and EHCI 2 as my usb controllers (since I turned xHCI off) so I guess I need to pass "ich9-usb-ehci1" and "ich9-usb-ehci2" as devices, instead of the 3 that I have in my original script (see first post). But what about "usb-ehci"? What does it do? Does it pass all my EHCI controllers? Or if I have more than one, I need the ich9-usb-ehci1 and 2?

EDIT: Here is my lspci: http://pastebin.com/8cRe59UZ

I never tested passing a entire controller so my answers are based of experience on other devices and logic.

-At this point, how should I pass my controllers for the guest? (using host=ID-FROM-LSPCI gave an error, I only need to specify the type of the controller to pass it like I did with xHCI?)

if it shows in lspci command then it recognized as pci device and the most likely method is pass just like the gpu with "-device vfio-pci,host=0X:XX.X".

however if a device is detected and claimed by a driver that might be problematic, since some drivers (and problably other things in your system or linux distro or hardware) causes problems when the hardware sundently disappears without the driver deregistering the device (which is what happens when you start the vm with with parameters that gives access to hardware like the -device vfio-pci,host... parameter) and that is why you generally have to backlist gpu modules prior the vm configuration to prevent these problem.

-If I pass the controller responsible for handling it, should I also pass the megalodon as an USB device?

No. Because if you pass the entire controller, the host side will loose control of that controller until you shutdown the vm, and because of that it cannot detect any devices connector to to the controller. so it is useless to do that. The error that you mentioned libusbx: error [_get_usbfs_fd] libusbx couldn't open USB device /dev/bus/usb/001/003: No such device is most likely caused by this because it cannot find the device since it does not have access to the controller.

-Should I pass both EHCI 1 and 2, or should I try to check which handles my megalodon (how do I do that?!)
-Could xHCI be helpful in solving my shitty audio quality, and if so how do I make it work with megalodon properly?

Not sure about this one. I think this going to depend on the bandwidth necessary for the card (usb 2.0 or usb 3.0) and the stability of the drivers on guest so. Some info on the qemu usb drivers capabilities can be found here: https://en.wikibooks.org/wiki/QEMU/Devices/USB/Root By the way, in the device manager of the guest, is controller listed correctly ? Does it need drivers installed ?

-Is it safe to pass all controllers to the guest, will the host be able to get a hold of all USB devices after guest terminates?

Check the instructions here: https://bbs.archlinux.org/viewtopic.php?id=162768 searching usb controller in first post and the ideia is unbind the device first (they call the script vfio-bind which also in the fist post) and the initiate the vm.

One thing you can test is instead of passing the entire controller, pass only one usb port. I do this and the are no error on my logs. The parameter is:

-device usb-host,bus=xhci.0,hostbus=3,hostport=11

to determine the hostbus and hostport run lsusb -t before and after plugging a device to pinpoint the port.

HOWEVER passing a usb port will probably give the same result as passing just device.

If you pass the controller check the device manager on windows and the its drivers.