Bug 1129961

Summary: qemu-kvm plays back audio at wrong sample rate
Product: [Fedora] Fedora Reporter: Andy Ross <andy>
Component: qemuAssignee: Fedora Virtualization Maintainers <virt-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 20CC: amit.shah, berrange, cfergeau, crobinso, dwmw2, itamar, louis, pbonzini, rjones, scottt.tw, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Windows   
Whiteboard:
Fixed In Version: qemu-1.6.2-8.fc20 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-09-11 00:54:58 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Andy Ross 2014-08-14 05:15:47 UTC
Description of problem:

I have a Win7 VM and am running it under the virt-manager qemu defaults (i.e. sound is "intel-hda").  Audio plays, but incorrectly downshifted.  After some testing, it seems clear that what is happening is that the windows driver is providing 48 kHz audio to the virtual hardware, but that qemu is feeding it to pulseaudio at 44.1 kHz.  Sounds are pitch-shifted lower, and streaming audio experiences "delays".  I can start playing a song, and if I wait long enough I can shut the VM down and the audio will *continue* playing for many seconds even after the OS that produced it is dead.

I'm pretty sure it's qemu's responsibility to get the sample rates matched, though it's possible there's a pulseaudio interaction too.

Version-Release number of selected component (if applicable):

qemu 1.6.2

How reproducible:

100%

Steps to Reproduce:
1. Create a VM in virt-manager, install any OS with sound output
2. Play music

Actual results:

Pitch is too low.  Audio stream buffers increasing amounts of data in the stream

Expected results:

It should sound the same in the VM as when played natively

Additional info:

Comment 1 Richard W.M. Jones 2014-08-14 07:42:08 UTC
*** Bug 1129962 has been marked as a duplicate of this bug. ***

Comment 2 Christophe Fergeau 2014-08-14 08:57:37 UTC
Are you using spice for display? This could have been broken with the addition of opus support :( If you are using spice, can you give details about which client you use to connect to the VM? virt-manager I guess? virt-manager/spice-gtk versions could be useful as well as the exact version of qemu that you are using (rpm -q qemu-system-x86)

Comment 3 Christophe Fergeau 2014-08-14 11:22:25 UTC
I've been able to reproduce with an up to date f20 through spice. This happens because the qemu package does not have this patch http://git.qemu.org/?p=qemu.git;a=commit;h=795ca114d353e02752a29f64902215bb30c58c21

I've pushed a qemu scratch build with this additional patch to http://koji.fedoraproject.org/koji/taskinfo?taskID=7301873 This fixes the issue for me, though spice-server also needs to handle that case.

Comment 4 Andy Ross 2014-08-14 16:10:33 UTC
Wow, that was fast.  Confirmed: the updated qemu build fixes the problem for me and I can now do calls with audio without falling behind.

And silly me for not realizing that spice did audio; I was assuming qemu was streaming it directly.

Comment 5 Christophe Fergeau 2014-08-19 09:26:55 UTC
For the record, I think this spice-server http://lists.freedesktop.org/archives/spice-devel/2014-August/017237.html will fix the problem for QEMU versions which don't have the patch from comment #3

Comment 6 Louis van Dyk 2014-08-22 14:27:10 UTC
I have the same problem on Fedora 20 64-bit, fully patched, on a Windows 8.1 guest, using virt-manager and spice to access the guest.

In fact, if playing audio, Avril Lavigne sounds like Evanescence, and if left long enough - about 2 tracks - the audio output quits completely from the delay, although the audio controls appear to be working.

This was unfortunate because I had an important Lync call yesterday - the only reason I have a Windows guest at all, and missed 75% of the conversation rebooting and signing in again each time the audio quit.

Versions:
qemu-system-x86-1.6.2-7.fc20.x86_64
spice-gtk3-0.23-3.fc20.x86_64
spice-server-0.12.5-2.fc20.x86_64
spice-vdagent-0.15.0-1.fc20.x86_64
virt-manager-1.0.1-3.fc20.noarch
virt-manager-common-1.0.1-3.fc20.noarch

When will the fix be released to the mainstream patches? 

Could someone tell me how to incorporate the fix above (comment 3)?  (Sorry, I have no idea what to do with src rpms)

Better still, could you tell me how to apply the spice.h update patch referred to (comment 5)?

THANKS as always!

Comment 7 Andy Ross 2014-08-22 15:24:13 UTC
Louis: there are binaries at that koji link, though the UI is a bit challenging.  Hit the "x86_64" link (or your desired architecture obviously) underneath "Descendents build ->".  You only need the qemu-system-x86 package (I think!), though I found qemu-common and qemu-kvm were required for dependencies.  Install the three with one "rpm -U" command.

And while I'd be really happy to be proven wrong, my experience is that Fedora is at best very mixed with support for non-critical bugs within a single release.  I wouldn't be surprised if this doesn't land in a core repo until F21.  I haven't checked rawhide to see if the fix is there or not, honestly.

(And FWIW: a failed Lync call was exactly the impetus for me filing this bug in the first place; I hadn't noticed the pitch-shifted boot chime, etc...)

Comment 8 Louis van Dyk 2014-08-22 15:35:53 UTC
Thanks Andy!!  I didn't click on the src.rpm's thinking "but I don't want the src, I want the compiled one!"  So we learn!

Well, let us hope you are proven wrong on THIS bug.  I personally don't think it's non-critical, for the very reason that it actually causes a failure in using the VM's audio.

But on the plus side, with Bugzilla by our side, our bugs are fixed quicker (sometimes) than the Microsoft bugs!  (I say sometimes because there have been some I have filed which really just have been ignored - not even a comment in the bug by the person it's assigned to!)

Comment 9 Fedora Update System 2014-09-08 16:30:53 UTC
qemu-1.6.2-8.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/qemu-1.6.2-8.fc20

Comment 10 Fedora Update System 2014-09-09 22:19:49 UTC
Package qemu-1.6.2-8.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing qemu-1.6.2-8.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-10445/qemu-1.6.2-8.fc20
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2014-09-11 00:54:58 UTC
qemu-1.6.2-8.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.