[Qemu-discuss] Audio from intel-hda & ich9-intel-hda pops & clicks

[Adam Zegelin]

Hi,

I have a Windows 10 VM that has an emulated intel-hda sound card
attached to it. Audio played via this device pops and clicks
repeatedly.

During normal use this VM has QEMU_AUDIO_DRV=pa to route the guest
audio to the host's sound card via pulseaudo. Host audio, such as
anything played via paplay, doesn't exhibit the quality degradation.

To rule out issues with qemu+pulseaudio I've tried running the VM with
QEMU_AUDIO_DRV=wav to capture the guest audio to a file. As a test, I
tried playing a 440 Hz pure sine wave from within the guest and then
inspected the qemu output/captured audio file with Audacity. There is
noticeable corruption of the recorded sine wave. It looks like samples
are being dropped.

The issue manifests itself as pops & clicks in the audio output.
Certain playback applications on the guest, such as MPC-HC (a video
player), eventually produce stuttering & looping audio for a period of
time before recovering, rendering these applications pretty much unfit
for purpose, unless you have a passion for stuttering video!

As an experiment I've tried:
- multiple versions of Windows
    - Windows 10 version 1511 (November Update), 1607 (Anniversary
Update) & 1703 (Creators Update)
    - Windows 8.1
- different output formats, set via the Device Properties -> Advanced
tab -> Default Format
    - 44100 Hz, 48000 Hz, 96000 Hz (even tried 16000 Hz)
- different playback applications on the guest
- removing all HyperV enlightenments
- disabling HPET via -no-hpet
- disabling HyperThreading on the host
- setting the CPU affinity of the qemu process to a single CPU (ie,
taskset -apc 0-5 <qemu PID>)
- changing the priority of the qemu process via renice to highest (eg, -20)
- -device usb-audio -- this kind-of works, for about 2 minutes before
all audio on the guest "hangs"

CPU load on the host or guest doesn't appear to have much impact on
the frequency of the dropped samples. Only time things got noticeably
worse was when I ran prime95 on the host. With the torture test
running the entire Windows VM was barely usable -- laggy mouse, slow
redraw, etc.

The host is:
- Arch Linux
- Linux 4.10.13-1-vfio #1 SMP PREEMPT Mon May 15 22:20:48 AEST 2017
x86_64 - GNU/Linux
- 2 x Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
- AsRock Rack EP2C612 WS


For testing with multiple OS versions I started qemu using the following script:

    #!/bin/bash -xue
    VM=$1
    ISO=$2
    SPICE_PORT=$3
    export QEMU_AUDIO_DRV=wav
    export QEMU_WAV_PATH=/home/adam/${VM}-audio.wav
    /usr/sbin/qemu-system-x86_64 \
        -realtime mlock=off \
        -nodefconfig -no-user-config -nodefaults -nographic \
        -name ${VM} \
        -machine q35,accel=kvm \
        -enable-kvm -cpu
host,kvm=off,hv_spinlocks=0x1fff,hv_relaxed,hv_time,hv_vapic,hv_vendor_id=Nvidia43FIX
\
        -rtc base=localtime,clock=host,driftfix=none \
        -m 1024  \
        -smp 2,cores=2,threads=1,sockets=1 \
        -monitor stdio \
        -device ich9-intel-hda -device hda-output \
        -boot order=c,menu=on,strict=on \
        -vga qxl -spice port=${SPICE_PORT},disable-ticketing -device
virtio-serial-pci -device
virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 -chardev
spicevmc,id=spicechannel0,name=vdagent \
        -drive 
file=/tank/fw/edk2.git-ovmf-x64-0-20170517.b2718.g7320b8e/OVMF-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on\
        -drive file=/tank/vm/${VM}-efivars.fd,if=pflash,format=raw,unit=1 \
        -object iothread,id=io1 \
        -device
virtio-scsi-pci,id=scsi0,ioeventfd=on,iothread=io1,num_queues=4 \
        -drive id=disk1,file=/tank/vm/${VM}.raw,format=raw,if=none,readonly=off
\
                -device scsi-hd,drive=disk1,bus=scsi0.0 \
        -drive id=disk2,file=fat:/home/adam/fatvol,if=none,readonly=on \
                -device scsi-hd,drive=disk2,bus=scsi0.0 \
        -drive file=/tank/i/virtio-win.iso,if=ide,media=cdrom \
        -drive id=cd0,file="${ISO}",format=raw,if=none,readonly=on \
                -device scsi-cd,drive=cd0,bus=scsi0.0 \
        -S

Regarding the -cpu ...kvm=off,...hv_vendor_id=Nvidia43FIX:
The audio symptoms also occur on a guest that has vfio-pci devices
attached, specifically a Nvidia GTX 970 & a USB3 PCIe host controller.
I actually use this VM as my daily Windows desktop machine --
everything works great except for the emulated intel-hda audio!
The issues still occur without the presence of these devices but I
left the -cpu options alone.

I would be grateful if anyone could offer some suggestions for a fix
to these audio issues.

I'm more than willing to help debug the problem further. I still have
the various Win10 & Win 8.1 test VMs laying around for this purpose.

Regards,
Adam