qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Narcis Garcia
Subject: Re: [Qemu-discuss] Audio from intel-hda & ich9-intel-hda pops & clicks
Date: Sun, 11 Jun 2017 17:47:35 +0200

Could you tell resultst with guests OS other than Microsoft Windows?


El 10/06/17 a les 15:26, Adam Zegelin ha escrit:
> 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
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]