Over the last few days, I have been working on a jack audiodev for Qemu which
I have just submitted upstream is now officially part of QEMU slated for 5.1 (https://github.com/qemu/qemu/blob/master/audio/jackaudio.c). In my testing, this fixes all stuttering/desync audio issues with all emulated Qemu audio devices in Windows and Linux.
As QEMU has introduced a new method of specifying the audiodev it’s now very simple to use this.
For example, an Intel HDA ICH9 device:
-audiodev jack,id=ad0 \ -device ich9-intel-hda \ -device hda-duplex,audiodev=ad0
The audio dev accepts some additional parameters:
|server-name||string||“default”||The JACK server instance to connect to|
|client-name||string||the VM’s name||The client name to use in JACK. This will have “out-” or “in-” prepended to it automatically based on the audio direction.|
|connect-ports||regex||If specified, automatically connect to ports matching the supplied regular expression|
|start-server||boolean||false||Set to true to autostart a jack instance if one is not present.|
|exact-name||boolean||false||Use the exact client name requested otherwise JACK generates a unique one, if needed.|
Note, for best performance the jack client thread needs realtime priority and will attempt to obtain it if possible, however, the QEMU
-runas can interfere with this. The requirements to make this work has been left as an exercise to the user (personally I just run Qemu as root )
Enjoy and have fun
EDIT: Updated link to version 4 of the patch. Just cosmetic code changes, documentation changes, and parameters have gone from using underscores (
_) to hyphens (
-) as per the QEMU standard practice.
EDIT: New version 5 patch, adds the ability to auto-connect to ports based on a regular expression match, as well as recovery if the jack server is restarted.
EDIT: New version 6 patch, fixes incorrect transport logic, audio stop no longer stops the JACK transport.
NOTE: QEMU has an internal resampler that we need to use, it is enabled by default but it’s designed to only handle sample rates up to 65.35kHz, do not expect this to work well at anything higher. This is not a limitation of this JACK audio dev, but QEMU itself. As such
jackd can not run at anything that exceeds this limit either. That said, the virtual audio devices are only 16-bit anyway, so if you are trying to get professional audio quality from QEMU then you need to go a different route (audio vfio passthrough) for now (I intend to correct this )