Bug 731235 - Intel-hda sound device can't play sound smothly
Summary: Intel-hda sound device can't play sound smothly
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Gerd Hoffmann
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-17 05:58 UTC by Chao Yang
Modified: 2013-01-10 00:14 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-12 10:38:08 UTC
Target Upstream Version:


Attachments (Terms of Use)
perf and kvm_stat info (10.75 KB, text/plain)
2011-09-15 09:06 UTC, Chao Yang
no flags Details

Description Chao Yang 2011-08-17 05:58:45 UTC
Description of problem:
Boot a windows 2k8R2 with intel-hda device, then play music with windows media player.

CLI:
# /usr/libexec/qemu-kvm -M rhel6.2.0 -enable-kvm -m 4096 -smp 4 -name win2k8r2sp1 -uuid 1b6c1dc5-e8f6-412d-9ce1-b3edefcdea36 -rtc base=localtime,clock=host,driftfix=slew -boot c -drive file=/mnt/stable-guest-ABI/win2k8r2sp1.qcow2,if=none,id=drive-ide-0-0,media=disk,format=qcow2,cache=none,werror=stop,rerror=stop -device ide-drive,drive=drive-ide-0-0,id=ide0-0-0  -netdev tap,id=hostnet1 -device rtl8139,netdev=hostnet1,id=net1,mac=64:31:50:41:e1:13  -usb -device usb-tablet,id=input1 -spice port=9000,disable-ticketing -vga qxl -monitor stdio -balloon none  -device intel-hda,id=sound0,bus=pci.0 -device hda-duplex

Version-Release number of selected component (if applicable):
# rpm -q qemu-kvm
qemu-kvm-0.12.1.2-2.183.el6.x86_64
# uname -r
2.6.32-188.el6.x86_64


How reproducible:
100%

Steps to Reproduce:
1.
2.
3.
  
Actual results:
play music disjointedly

Expected results:
play music smoothly

Additional info:
hit same issue with -device intel-hda,id=sound0,bus=pci.0 -device hda-output

Comment 2 Dor Laor 2011-09-12 07:12:42 UTC
Can you please repeat the test with win7 or winxp VM?
We need to see if it is guest specific or not.

In addition, please test it w/o spice, using local sound. Spice might be the cause for the interruptions.

Comment 3 Gerd Hoffmann 2011-09-12 08:28:49 UTC
Win7 (likely w2k8 too) uses a quite small ring buffer.  It's less than 4k, with sound data for 20 miliseconds fitting in.  Which implies that pretty much any latency bug in qemu will be noticable here.  It works reasonable for me with an idle guest.  Any disk I/O causes auditable dropouts.  Merging coroutines for qcow2 should improve the situation noticable.  There might be more issues latency lurking though.

There isn't much I can do about this in the intel-hda emulation code.

Comment 4 Chao Yang 2011-09-14 07:58:11 UTC
(In reply to comment #2)
> Can you please repeat the test with win7 or winxp VM?
> We need to see if it is guest specific or not.
> 
> In addition, please test it w/o spice, using local sound. Spice might be the
> cause for the interruptions.

I only tested win7 and win2k8r2 since no driver for winxp. Both win7 and win2k8r2 can reproduce this issue with local sound(no matter vnc or spice), but not every time. I noticed that qemu consumed 40% CPU and 70% MEM resource in my host when this issue reproduced.

CLI:
# /usr/libexec/qemu-kvm -M rhel6.2.0 -enable-kvm -m 4096 -smp 2 -uuid b5d1b5f3-6272-4c30-a080-ebb96fb1ec49 -rtc base=localtime,clock=host,driftfix=slew -boot dc -drive file=/root/bz731235/win7-x96_64.qcow2,if=none,id=drive-ide-0-0,media=disk,format=qcow2,cache=none,werror=stop -device ide-drive,drive=drive-ide-0-0,id=ide0-0-0 -netdev tap,id=hostnet1 -device rtl8139,netdev=hostnet1,id=net1,mac=64:31:50:41:e1:13 -usb -device usb-tablet,id=input1 -vga qxl -spice port=9000,disable-ticketing -monitor stdio -balloon none -device intel-hda,id=sound0,bus=pci.0 -device hda-output -drive file=/root/bz731235/en_windows_7_ultimate_with_sp1_x64_dvd_618240.iso,if=none,media=cdrom,readonly=on,format=raw,id=drive-cdrom -device ide-drive,drive=drive-cdrom,id=cdrom

Comment 5 Chao Yang 2011-09-14 08:00:53 UTC
(In reply to comment #3)
> Win7 (likely w2k8 too) uses a quite small ring buffer.  It's less than 4k, with
> sound data for 20 miliseconds fitting in.  Which implies that pretty much any
> latency bug in qemu will be noticable here.  It works reasonable for me with an
> idle guest.  Any disk I/O causes auditable dropouts.  Merging coroutines for
> qcow2 should improve the situation noticable.  There might be more issues
> latency lurking though.
>
I did nothing but played music when guest booted up.

Comment 6 Gerd Hoffmann 2011-09-14 08:54:25 UTC
Re #4: 40% CPU looks unusual high for an (almost) idle machine just playing music.  Worth looking where this comes from.  Any chance windows runs some background tasks?

Comment 7 Chao Yang 2011-09-14 10:29:30 UTC
(In reply to comment #6)
> Re #4: 40% CPU looks unusual high for an (almost) idle machine just playing
> music.  Worth looking where this comes from.  Any chance windows runs some
> background tasks?

Top shows 40% CPU consuming when windows booted up, and in guest, CPU usage is less than 5% when playing music

Comment 8 Dor Laor 2011-09-15 06:36:40 UTC
Can you please show what kvm_Stat and perf show on the host?

Comment 9 Chao Yang 2011-09-15 09:05:27 UTC
(In reply to comment #8)
> Can you please show what kvm_Stat and perf show on the host?

Please see the attachment.

Comment 10 Chao Yang 2011-09-15 09:06:40 UTC
Created attachment 523331 [details]
perf and kvm_stat info

Comment 12 Gerd Hoffmann 2011-11-03 12:44:56 UTC
Is there a significant load difference between playing and not playing music?
Or is the qemu-kvm load for a completely idle win7 machine unusual high too?
Which wakeup rate does powertop show for qemu-kvm?

Comment 13 Chao Yang 2011-11-08 09:09:56 UTC
(In reply to comment #12)
> Is there a significant load difference between playing and not playing music?
> Or is the qemu-kvm load for a completely idle win7 machine unusual high too?
> Which wakeup rate does powertop show for qemu-kvm?

Currently I can't reproduce this issue after I fresh installed this box, but will try more and update here

Comment 14 Gerd Hoffmann 2011-11-11 12:27:47 UTC
Looked at it with top and perf a bit.

In top you can enable thread display with Shift-H, you'll see at least three threads.  The first is the I/O thread, second is the vcpu (on a smp guest you'll have one thread per vcpu), third is the spice server thread.  There might be additional threads to serve disk I/O which are created and destroyed on demand.

perf allows to watch individual threads using the -t option in both 'perf top' and 'perf record'.

What I'm seeing here is alot of little things summing up:

  (1) First win7 doesn't use remote suspend for the usb tablet,
      so usb runs even with an inactive tablet and burns some CPU.
      Googled around a bit and didn't found a solution to that.

  (2) Windows itself (task manager) reports 10% cpu usage.

  (3) vcpu thread uses about 20% cpu.  Looks pretty high at first,
      but remember (see comment 3) that the buffer is pretty small.
      So we have a pretty high interrupt rate because of that and
      thus a high number of vmexits.  So a noticable overhead isn't
      surprising.  Also my laptop hasn't EPT, so there is softmmu
      overhead too.

  (4) The I/O thread does audio compression (celt codec) and needs
      some CPU for that.

In the end I see ~40% cpu load on my laptop (T500) too.

Comment 15 Gerd Hoffmann 2011-12-12 10:38:08 UTC
So while the cpu load looks pretty high at first it seems to be just the virtualization overhead.

That leaves the original issue of music playing disjointedly.  Not reproducable any more for the reporter according to comment #13, so I'll go close it.  Please reopen in case the bug shows up again.


Note You need to log in before you can comment on or make changes to this bug.