[Qemu-devel] [Bug 1795527] Re: Malformed audio and video output stuttering after upgrade to QEMU 3.0

[tlloss]

GIT BISECT RESULTS

So, I managed to run the git bisection and ended up having to do it
twice: once looking for the first commit that broke audio (turns out a
major total breakage occurs before the original diagnosed issue
appeared), then to spot the origin of the main issue (I ignored the
other form of malfunctioning, marking it as 'good').

---AUDIO BREAKAGE BISECT LOG---

git bisect start
# bad: [53a19a9a5f9811a911e9b69ef36afb0d66b5d85c] s390x/tcg: always enable AFP 
for linux-user
git bisect bad 53a19a9a5f9811a911e9b69ef36afb0d66b5d85c
# good: [4743c23509a51bd4ee85cc272287a41917d1be35] Update version for v2.12.0 
release
git bisect good 4743c23509a51bd4ee85cc272287a41917d1be35
# bad: [7f9ddf64d5fe5bfaa91ae0ec52217d86f4d86452] target/arm: Implement SVE 
Floating Point Accumulating Reduction Group
git bisect bad 7f9ddf64d5fe5bfaa91ae0ec52217d86f4d86452
# good: [cc9743c236cce8a35449e3ef67140287b68bb705] iscsi: Query and save device 
designator when opening
git bisect good cc9743c236cce8a35449e3ef67140287b68bb705
# good: [1e05197f24c49d52f339de9053bb1d17082f1be3] translate-all: iterate over 
TBs in a page with PAGE_FOR_EACH_TB
git bisect good 1e05197f24c49d52f339de9053bb1d17082f1be3
# good: [2aeba0d007d33efa12a6339bb140aa634e0d52eb] target/arm: Strict alignment 
for ARMv6-M and ARMv8-M Baseline
git bisect good 2aeba0d007d33efa12a6339bb140aa634e0d52eb
# bad: [00928a421d47f49691cace1207481b7aad31b1f1] Merge remote-tracking branch 
'remotes/pmaydell/tags/pull-target-arm-20180626' into staging
git bisect bad 00928a421d47f49691cace1207481b7aad31b1f1
# bad: [35e238c9330669882487f9929e0aa97900431853] Merge remote-tracking branch 
'remotes/kraxel/tags/audio-20180625-pull-request' into staging
git bisect bad 35e238c9330669882487f9929e0aa97900431853
# good: [c52e53f429aa562539f5da2e7c21c66c6f9a8a16] Merge remote-tracking branch 
'remotes/dgibson/tags/ppc-for-3.0-20180622' into staging
git bisect good c52e53f429aa562539f5da2e7c21c66c6f9a8a16
# good: [be25fcc4d2faeb3ffa8db813272963bae659c4c2] MAINTAINERS: Update QAPI 
stanza for commit fb0bc835e56
git bisect good be25fcc4d2faeb3ffa8db813272963bae659c4c2
# good: [518d23a976b7dad77cfef3e41c3531ac89229b00] Merge remote-tracking branch 
'remotes/ehabkost/tags/python-next-pull-request' into staging
git bisect good 518d23a976b7dad77cfef3e41c3531ac89229b00
# bad: [8ced0669237b2bbedac3e4ce6fcf7aaaafaae663] audio/hda: tweak timer adjust 
logic
git bisect bad 8ced0669237b2bbedac3e4ce6fcf7aaaafaae663
# bad: [0a373bb310c1533e24aa5e3edbf206507fb342ea] audio/hda: turn some dprintfs 
into trace points
git bisect bad 0a373bb310c1533e24aa5e3edbf206507fb342ea
# bad: [280c1e1cdb24d80ecdfcdfc679ccc5e8ed7af45d] audio/hda: create millisecond 
timers that handle IO
git bisect bad 280c1e1cdb24d80ecdfcdfc679ccc5e8ed7af45d
# first bad commit: [280c1e1cdb24d80ecdfcdfc679ccc5e8ed7af45d] audio/hda: 
create millisecond timers that handle IO

---END---


---ORIGINAL ISSUE BISECT LOG---

git bisect start
# bad: [35e238c9330669882487f9929e0aa97900431853] Merge remote-tracking branch 
'remotes/kraxel/tags/audio-20180625-pull-request' into staging
git bisect bad 35e238c9330669882487f9929e0aa97900431853
# good: [c52e53f429aa562539f5da2e7c21c66c6f9a8a16] Merge remote-tracking branch 
'remotes/dgibson/tags/ppc-for-3.0-20180622' into staging
git bisect good c52e53f429aa562539f5da2e7c21c66c6f9a8a16
# good: [cc2ae7c9de14efd72c6205825eb7cd980ac09c11] target/arm: Introduce 
ARM_FEATURE_M_MAIN
git bisect good cc2ae7c9de14efd72c6205825eb7cd980ac09c11
# good: [be25fcc4d2faeb3ffa8db813272963bae659c4c2] MAINTAINERS: Update QAPI 
stanza for commit fb0bc835e56
git bisect good be25fcc4d2faeb3ffa8db813272963bae659c4c2
# good: [518d23a976b7dad77cfef3e41c3531ac89229b00] Merge remote-tracking branch 
'remotes/ehabkost/tags/python-next-pull-request' into staging
git bisect good 518d23a976b7dad77cfef3e41c3531ac89229b00
# good: [8ced0669237b2bbedac3e4ce6fcf7aaaafaae663] audio/hda: tweak timer 
adjust logic
git bisect good 8ced0669237b2bbedac3e4ce6fcf7aaaafaae663
# bad: [bc753dc09ff33d99bc9004d7286c50de1d5bece6] audio/hda: enable new timer 
code by default.
git bisect bad bc753dc09ff33d99bc9004d7286c50de1d5bece6
# good: [4501ee16c76e89e0a2b2beb95f3b93f965997391] audio/hda: detect output 
buffer overruns
git bisect good 4501ee16c76e89e0a2b2beb95f3b93f965997391
# first bad commit: [bc753dc09ff33d99bc9004d7286c50de1d5bece6] audio/hda: 
enable new timer code by default.

---END---


I'm attaching both of them, just in case someone wants to replay them.

One thing that I'd like to point out is that the thing I called "total 
breakage" looks extremely similar to what happens when I set a 2.12 machine on 
a 3.0 QEMU: complete distortion.
Do I have to study it more in order to see if it really produces the same 
effect?


Anyway, I'm sorry if such a simple matter took this long but, during one of the 
initial bisections, an accidental misconfiguration in the testing environment 
completely wasted the guest I was using (permanent Windows startup 
failure-level of wasted...).
I had to recover a few things and reinstall as many.

** Attachment added: "[AUDIO BREAKAGE LOG]"
   
https://bugs.launchpad.net/qemu/+bug/1795527/+attachment/5210396/+files/qemu_bisect_total_audio_breakage.txt

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1795527

Title:
  Malformed audio and video output stuttering after upgrade to QEMU 3.0

Status in QEMU:
  New

Bug description:
  My host is an x86_64 Arch Linux OS with a recompiled 4.18.10 hardened
  kernel, running a few KVM guests with varying OSes and configurations
  managed through a Libvirt stack.

  Among these guests I have two Windows 10 VMs with VGA passthrough and
  PulseAudio-backed virtual audio devices.

  After upgrading to QEMU 3.0.0, both of the Win10 guests started
  showing corrupted audio output in the form of unnatural reproduction
  speed and occasional but consistently misplaced audio fragments
  originating from what seems to be a circular buffer wrapping over
  itself (misbehaviour detected by starting some games with known OSTs
  and dialogues: soundtracks sound accelerated and past dialogue lines
  start replaying middle-sentence until the next line starts playing).

  In addition, the video output of the malfunctioning VMs regularly
  stutters roughly twice a second for a fraction of a second (sync'ed
  with the suspected buffer wrapping and especially pronounced during
  not-pre-rendered cutscenes), toghether with mouse freezes that look
  like actual input misses more than simple lack of screen refreshes.

  
  The issue was succesfully reproduced without the managing stack, directly 
with the following command line, on the most capable Windows guest:

   QEMU_AUDIO_DRV=pa
   QEMU_PA_SERVER=127.0.0.1
   /usr/bin/qemu-system-x86_64 -name guest=win10_gms,debug-threads=on \
   -machine pc-i440fx-3.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off \    
                                                                                
                                                       
   -cpu 
host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vendor_id=123456789abc,kvm=off
 \          
   -drive 
file=/usr/share/ovmf/x64/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \ 
      
   -drive 
file=/var/lib/libvirt/qemu/nvram/win10_gms_VARS.fd,if=pflash,format=raw,unit=1 \
   -m 5120 \                                                                    
          
   -realtime mlock=off \
   -smp 3,sockets=1,cores=3,threads=1 \
   -uuid 39b56ee2-6bae-4009-9108-7be26d5d63ac \
   -display none \                             
   -no-user-config \
   -nodefaults \    
   -rtc base=localtime,driftfix=slew \                                          
                                                                                
                                                       
   -global kvm-pit.lost_tick_policy=delay \                                     
                             
   -no-hpet \                              
   -no-shutdown \
   -global PIIX4_PM.disable_s3=1 \
   -global PIIX4_PM.disable_s4=1 \
   -boot strict=on \              
   -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x4.0x7 \
   -device 
ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x4 \
   -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x4.0x1 \  
           
   -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x4.0x2 \
   -device ahci,id=sata0,bus=pci.0,addr=0x9 \                                 
   -drive 
file=/dev/vms/win10_gaming,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native
 \
   -device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1,write-cache=on
 \
   -drive 
file=/dev/sr0,format=raw,if=none,id=drive-sata0-0-0,media=cdrom,readonly=on \   
                                 
   -device ide-cd,bus=sata0.0,drive=drive-sata0-0-0,id=sata0-0-0 \              
       
   -device intel-hda,id=sound0,bus=pci.0,addr=0x3 \                             
                                                                                
                                                       
   -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \                     
                        
   -device usb-host,hostbus=2,hostaddr=3,id=hostdev0,bus=usb.0,port=1 \
   -device vfio-pci,host=01:00.0,id=hostdev1,bus=pci.0,addr=0x6 \      
   -device vfio-pci,host=01:00.1,id=hostdev2,bus=pci.0,addr=0x7 \
   -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 \   
   -sandbox 
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
   -msg timestamp=on

  
  By "purposedly misconfiguring" the codepaths and replacing "pc-i440fx-3.0" 
with "pc-i440fx-2.11" (basically reverting the config changes I needed to do in 
order to update the domain definitions), the stuttering seems to disappear (or 
at least becomes negligible) and the audio output, despite becoming incredibly 
distorted, is consistent in every other way, with in-order dialogues and 
(perceived) correct tempo.

  
  In order to exclude eventual misconfigurations in the host's audio processing 
pipeline, I proceeded to update the domain definition's codepath of another 
guest running Ubuntu 18.04 with a completely different hardware configuration 
(no video card passthrough and no PulseAudio backconnection, just a plain 
emulated VirtIO display and Spice audio device).

  The audio issue presented itself again in the form of slightly sped up audio 
playback from Internet videos interleaved with occasional "quenches" of playing 
speed.
  Stutters are difficult to detect because of the poor refresh rate of the 
emulated VGA adapter, but I wouldn't be surprised to find them here too 
(actually, I *think* I sensed them, but I'm not sure enough to assess their 
existence).

  Once again, by reverting to the old 2.11 directive everything is back
  to normal.


  Given the fact that no official upgrade directives regarding required 
sampling rate, period or sheduling adjustments were stated or handed-out to 
administrators, I decided to report this behaviour as a bug.
  I hope this is the appropriate channel and that I didn't annoy anyone (this 
is my first proper bug report, please forgive me for any innaccuracy).

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1795527/+subscriptions