You are not logged in.
I launch a qemu-kvm with vga passthrough and I managed so far to make it work pretty well. All works well except the microphone. I used -device intel-hda -device hda-micro and the Intel HDA device installed on the guest with a microphone that works and I can hear what I say on it. BUT I hear it after 25-27 seconds later!
I run the VM with one of these envs:
QEMU_PA_SAMPLES=2 QEMU_AUDIO_DRV=pa
EMU_ALSA_DAC_BUFFER_SIZE=64 QEMU_ALSA_DAC_PERIOD_SIZE=170 QEMU_AUDIO_DRV=alsa
both exhibit the same delay.
Anyone has any clues of where this extreme buffering (probably misconfiguration) comes from so I can fix it?
Last edited by Nektarios (2015-05-30 18:49:22)
Offline
Is it a USB headset? Try USB passthrough
example -usb -device usb-ehci,id=ehci -device usb-host,bus=ehci.0,vendorid=0x04a9,productid=0x1759
the id you get with lsusb
Last edited by frostschutz (2015-05-30 19:01:37)
Offline
No, it's an onboard intel audio chip and I don't want it to get it passed through, I want to have sound on the host too.
Offline
I have the exact same issue when using HDA audio card for qemu. The output works fine, however the microphone input has a very long lag. I can passthrough the USB sound card and it works perfectly, but I really wanted to make use of pulseaudio device selection to change my input and output device on the fly.
Using ac97 sound card, there is no input lag. But it doesn't have a proper Windows 7 x64 driver, which causes choppy audio.
Last edited by dhiru1602 (2015-06-13 23:10:16)
Offline
Hi,
I got the exact same issue, it is very strange that the delay is so high... No one found a solution from the first time the topic has been created?
I am very interesting to any workaround / solution
many thanks
Offline
Running into this as well.
Offline
Ran into this issue myself, but after a lot of trying out all of the audio options for Qemu I found that QEMU_AUDIO_TIMER_PERIOD=200 (default is 100, anything higher seems to work fine, didn't try lower) mostly fixes the issue for me.
It sometimes still lags behind but skips forward until it works just fine. Tried in both Windows 10 as well as Linux VMs.
Using ALSA instead also fixes the delay, but causes horribly choppy audio and still causes delays after running the VM for a few hours.
Found this on their bugtracker: https://bugs.launchpad.net/qemu/+bug/1492649
Offline
I've done a bit of research on this, and it's not for the feint of heart, but there is a patch for qemu floating out there that explicitly solves this issue. It comes down to recompiling qemu with the patch applied and I've confirmed that the issue with the microphone input delay has been resolved.
The resolution can be found in this thread: https://lists.gnu.org/archive/html/qemu … 03336.html
It's been a bit since the last update and according to the git repo for qemu, (current master), I have not seen this fix go in. As to the details (sourced from the thread): Without setting proper buffer attributes, pulseaudio has a buffer ~24s in length (4MB of 16bit stero audio, 44.1kHz). It turns out that qemu opens a connection to pulseaudio and immediately starts recording to the ringbuffer. The guest, (in my case windows, and I'm sure many others) doesn't consume data if there isn't a process listening on the audio interface. If something starts recording, it will start collecting data approximately 24s delayed because of the ringbuffer that has been filled. This patch looks to be setting appropriate buffer attributes.
All of this information is credited to Volker Rümelin (see the above linked thread).
Using ALSA absolutely should fix the delay as there is no longer the ringbuffer involved.
NOW, do I recommend recompiling qemu to fix this? If you feel up to it, sure. I'm not sure if there is an AUR package that includes this. If there is interest I may look into submitting a package with this patch included. That being said, I believe that (based on the thread) it should be possible to get this fix upstream.
Cheers!
(Answered this here as this thread seems to be top of the google search for qemu microphone delay)
Offline
Thanks a lot for sharing that, interesting.
Did this patch get left behind? The discussion seem to have just died around it.
Offline
Thanks a lot for sharing that, interesting.
Did this patch get left behind? The discussion seem to have just died around it.
I'm not really sure. I can look into it as I have some spare bandwidth. It may just need a little cleanup (based on the last message in the thread)
Offline
As a bit of a further update there is a little bit of stutter introduced in 3D rendering since I applied this patch, I think one of the values is causing a little stutter. I'll dig around a bit more and see if there is something going on (it also may be down to chipset emulation -- 1440fx vs q35, or something going on in QEMU 2.6 instead of 2.5 [what I was previously using]). It isn't super noticeable most of the time, but occasionally since I applied this I'll get a stutter (I need to look to see if it's a legit framedrop or something else; avg 85-90FPS or so, 4k UHD 60hz on Display Port connection, latest drivers). I'll have to attack this stutter from the QEMU side rather than windows (since I'm not a windows guru).
Offline
Is there anything in particular I could help with? I have never tried compiling qemu, but if it's not too tricky, I could do some performance benchmarks with your patch, my windows VM is set up in a way that I can boot it either natively, or through qemu.
Offline
Ah, my last reply got eaten. Turns out broken hardware does weird things. Had to RMA a video card.
I've also been tuning PA ENV vars in my startup to reduce/limit static and improve PulseAudio responses. Generally I'm pretty happy with everything now. I am seeing a minor delay still on mic pickup depending on the QEMU_PA_SAMPLES variable (expected and PULSE_LATENCY_MSEC, which has proven to be useful to smoothout the poor audio quality being passed back to the host).
Generally compiling qemu isn't hard. Any extra data points would be nice (that this works/doesn't cause issues), I do recommend only compiling the stable release(s) [current is 2.6.3 iirc] and not just HEAD.
Offline
Sorry I got a little tied up.
When I try to apply the patch in the link, I get
fatal: corrupt patch at line 6
I'm trying to apply on top of v2.6.0.
Offline
I hacked together the PKGBUILD from qemu-git with the patch from the mailing list if anyone would like to use it.
git clone https://aur.archlinux.org/qemu-git.git
Download https://gist.github.com/Flat/fc9933b3eb … 1b6404195d as raw and save it wherever as whatever you want.
git apply papatch.diff && makepkg
There's still about a half-second to a second of lag on the input but it's nothing unbearable.
自分を信じなさい(´・ω・`)
Offline
Thanks a lot! I'm going to leave it compiling and come back to it tomorrow morning, will leave feedback on how it works for me.
Offline
I get the same results with the patch applied too (at least with using Flat's package), the same 25 seconds delay is there
Last edited by WishCow (2016-08-08 11:37:29)
Offline
Are you sure the patch applied?
Also output of
pacman -Qs qemu-git
?
Last edited by Flat (2016-08-08 20:48:12)
自分を信じなさい(´・ω・`)
Offline
wishcow ~ $ pacman -Qs qemu-git
local/qemu-git 2.7.0.r47693.5100917-1
A generic and open source processor emulator which achieves a good emulation speed by using dynamic translation. Git version.
Are you passing in a USB headset, or are you changing the sink for qemu through pavuctrl? I'm doing the latter.
Offline
I use a USB microphone, but it is through pulseaudio. No USB-passthrough. This is the relevant part I use for audio.
<sound model='ich9'>
<codec type='micro'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</sound>
<qemu:commandline>
<qemu:env name='QEMU_PA_SAMEPLES' value='4096'/>
<qemu:env name='QEMU_AUDIO_DRV' value='pa'/>
<qemu:env name='QEMU_PA_SOURCE' value='alsa_input.usb-BLUE_MICROPHONE_Blue_Snowball_201109-00.analog-stereo'/>
</qemu:commandline>
The input does show up in pavucontrol.
自分を信じなさい(´・ω・`)
Offline
I'm not using libvirt, but I added the environment variables (there is a typo in your PA_SAMPLES one), but they didn't make a difference. My relevant lines:
-device hda-micro \
-soundhw hda \
Offline
Ha, can't believe I missed that typo. Thanks for pointing that out. But yeah it should be fairly similar even if you don't use libvirt. Not sure what the difference would be that it works for me and not yourself then though.
自分を信じなさい(´・ω・`)
Offline
I found a workaround that works for me. Pass in the USB device with -usbdevice, and set the sample rate to "16 bit, 48000 Hz (DVD Quality)" in Windows for the device. As unlikely as it sounds, it works.
Credit to https://r000t.com/fixing-qemu-poor-usb-audio-quality/.
Offline
The main problem I have with just passing the usb device is then I can't use the device on my host, its really a shame they've been all but ignoring this issue upstream.
Last edited by Flat (2016-10-22 17:18:02)
自分を信じなさい(´・ω・`)
Offline
https://aur.archlinux.org/packages/qemu-saren-git/ is an AUR package with the patch.
Offline