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):
Steps to Reproduce:
1. Create a VM in virt-manager, install any OS with sound output
2. Play music
Pitch is too low. Audio stream buffers increasing amounts of data in the stream
It should sound the same in the VM as when played natively
*** Bug 1129962 has been marked as a duplicate of this bug. ***
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)
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.
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.
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
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.
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!
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...)
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!)
qemu-1.6.2-8.fc20 has been submitted as an update for Fedora 20.
* 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:
then log in and leave karma (feedback).
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.