BTW, there is no problem when playing a song on the host system with the USB headset.

This is also happening to me with ich6/ich9 audio devices. I believe the problem may be related to wrong output frequency as suggested in the mail list [0]

[0] http://lists.nongnu.org/archive/html/qemu-devel/2014-12/msg02720.html

Thanks for the info, please keep me updated if there is a fix.

A workaround is to pass through the USB controller where my USB headset is attached and it works much better.

BTW, pass through only the USB headset device to guest doesn't solve the problem, there is background noises all the time when there is sound output, e.g. when I'm playing music, but the noise will go away when there is no sound being played.

And Linux guest on this same host doesn't have problem with the emulated ICH6 sound device.

elmarco, I thought there was another bug or qemu patches that mentioned audio frequency and windows VMs, but I can't find anything now. Do you know what this is about?

When I manually start the vm with the following cmdline, sound doesn't have any problem:
qemu-kvm -drive file=win7.qcow2,if=virtio,cache=unsafe -net nic,model=virtio -net bridge,br=virbr0 -usbdevice tablet -m 4096 -smp 2 -vga std -soundhw hda

And the cmdline used by virt-manager is(got from ps -ax):
4243 ?        Rl     0:16 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name win7 -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu SandyBridge,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 5b839035-10b3-4961-b5cc-aa6b7c0ebaf2 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -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=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/home/aaron/vm/windows/win7.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=unsafe -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:82:96:81,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on

(In reply to Cole Robinson from comment #6)
> elmarco, I thought there was another bug or qemu patches that mentioned
> audio frequency and windows VMs, but I can't find anything now. Do you know
> what this is about?

In the ML there are some reports about opus being problematic, and I think there were some temporary regressions wrt audio frequency. Tbh, I didn't reach this kind of codec issues yet, and I haven't been involved much with that, but Christophe did iirc.

An easy to reproduce glitch with Windows is reported in bug #1203507, and after a quick look it seems to be a buffering issue on qemu-side, but more research are necessary.

I believe this problem is related to spice: when I do not use the -spice switch as I posted in comment #7, the sound doesn't have any problem; when I add -spice and use vinagre to connect to the spice session(I believe this is the same thing as I use virt-manager to view the guest), the sound is broken.

So I'm moving this bug to spice.

Turned out it has something to do with the -playback-compression switch of spice: when I set it to off, the sound is OK with spice; and when it is the default on, the sound quality is bad.

The above test is with vinagre. Then I used virsh edit win7 and added the <playback compression='off'/> line under the graphics line, the guest started from virt-manager still has bad sound quality. I verified that the playback-compression=off is passed to qemu in the -spice switch options.

I have no idea why this is the case, I suppose vinagre also uses libspice as virt-manager and they should behave the same?

Full cmdline used with vinagre:
qemu-kvm -drive file=win7.qcow2,if=virtio,cache=unsafe -net nic,model=virtio -net bridge,br=virbr0 -usbdevice tablet -m 4096 -smp sockets=1,cores=2,threads=1 -vga qxl -soundhw hda -spice port=5900,ipv4,password=XXXXXX,playback-compression=off -display none

Full cmdline used by virt-manager(got from ps -ax):
4632 ?        Sl     0:03 /usr/bin/qemu-system-x86_64 -machine accel=kvm -name win7 -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu qemu64,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -m 4096 -realtime mlock=off -smp 2,sockets=1,cores=2,threads=1 -uuid f3d39afc-c8df-46bb-9fbd-4a26394a655f -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/win7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime,driftfix=slew -global kvm-pit.lost_tick_policy=discard -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=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/home/aaron/vm/windows/win7.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:66:cd:e8,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing,playback-compression=off,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on

Changing the frequency in the client can solve the problem as suggested in comment #2

With opus or celt, client tries to decode at 48kHz when audio comes at 44,1kHz.
I'm trying to fix this properly now;

Aaron,

Could you check if you still have the problem using ac97 audio driver instead of intel-hda? I believe the problem is a duplicate of bug #1203507 (driver problem).

The workaround I did on comment #12 was misleading. I was not able to find on SPICE wrong procedures of audio encoding and decoding... even RAW audio has output problems.

You could also check both intel-hda and ac97 using QEMU_AUDIO_DRV=pa which makes the audio going from QEMU directly to pulseaudio (instead of spice -> spice-gtk -> pulseaudio).

I've notice that with ac97 the sounds is perfect but with intel-hda we have great amount of noise.

As per https://bugzilla.redhat.com/show_bug.cgi?id=1203507#c9 this is a regression between v2.0.0 and v1.7.2.

Moving to QEMU.

(In reply to Victor Toso from comment #13)
> Aaron,
> 
> Could you check if you still have the problem using ac97 audio driver
> instead of intel-hda? I believe the problem is a duplicate of bug #1203507
> (driver problem).

Unfortunately, there is no ac97 win7 64bits driver AFAIK.

I had the same problem. As a workaround, I changed the audio driver to ac97 and downloaded the Realtek drivers "Vista/Win7 (32/64 bits) Driver only (ZIP file)" from [1] and added them to the unknown audio device within the device manager.

Afterwards the playback went OK.

[1] http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=14&PFid=23&Level=4&Conn=3&DownTypeID=3&GetDown=false

(In reply to Christian Affolter from comment #16)
> I had the same problem. As a workaround, I changed the audio driver to ac97
> and downloaded the Realtek drivers "Vista/Win7 (32/64 bits) Driver only (ZIP
> file)" from [1] and added them to the unknown audio device within the device
> manager.
> 
> Afterwards the playback went OK.
> 
> [1]
> http://www.realtek.com.tw/downloads/downloadsView.
> aspx?Langid=1&PNid=14&PFid=23&Level=4&Conn=3&DownTypeID=3&GetDown=false

Nice, works for me too, thanks for the link!

(In reply to Aaron Lu from comment #17)
> (In reply to Christian Affolter from comment #16)
> > I had the same problem. As a workaround, I changed the audio driver to ac97
> > and downloaded the Realtek drivers "Vista/Win7 (32/64 bits) Driver only (ZIP
> > file)" from [1] and added them to the unknown audio device within the device
> > manager.
> > 
> > Afterwards the playback went OK.
> > 
> > [1]
> > http://www.realtek.com.tw/downloads/downloadsView.
> > aspx?Langid=1&PNid=14&PFid=23&Level=4&Conn=3&DownTypeID=3&GetDown=false
> 
> Nice, works for me too, thanks for the link!

ac97 sound quality is much better than intel-hda(ICH6 & ICH9).but ac97 has long run no sound bug.
playing a local video on VM loop about 40 hours,VM get no sound,and video freeze.
disable AC97 device and enable it on windows device manager sound comes.

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Are people still hitting these issues with fedora 22 or later? If so please adjust the bug version

The problem is still there in Fedora 23.

The sound quality is good with playback-compression=off switch like this:
qemu-kvm -drive file=win7.qcow2,if=virtio,cache=unsafe -net nic,model=virtio,macaddr=52:54:00:66:cd:e8 -net bridge,br=virbr0 -usbdevice tablet -m 2048 -smp 2 -vga qxl -soundhw hda -spice port=5900,ipv4,password=xxxxxx,playback-compression=off -display none

If I omit the playback-compression=off switch, the sound quality is bad. This only happens with spice, I don't know if I should also change the component?

(In reply to Victor Toso from comment #13)
> You could also check both intel-hda and ac97 using QEMU_AUDIO_DRV=pa which
> makes the audio going from QEMU directly to pulseaudio (instead of spice ->
> spice-gtk -> pulseaudio).

I didn't know how I'm supposed to do that the first time I saw this comment, but since I'm checking again, I decided to give it a try.

The QEMU_AUDIO_DRV=pa looks like an environment variable, so I did this:
$ export QEMU_AUDIO_DRV=pa
$ qemu-kvm -drive file=win7.qcow2,if=virtio,cache=unsafe -net nic,model=virtio,macaddr=52:54:00:66:cd:e8 -net bridge,br=virbr0 -usbdevice tablet -m 2048 -smp 2 -vga qxl -soundhw hda -spice port=5900,ipv4,password=123456 -display none

I didn't use -playback-compression=off switch in the above qemu cmdline options so the sound should be bad. But now with the QEMU_AUDIO_DRV=pa, the quality is pretty good. So I would say this environment variable setting also fixed the sound quality problem, thanks!

Just realized that bypassing spice also means no sound output when connecting the VM through another machine...

(In reply to Aaron Lu from comment #22)
> (In reply to Victor Toso from comment #13)
> > You could also check both intel-hda and ac97 using QEMU_AUDIO_DRV=pa which
> > makes the audio going from QEMU directly to pulseaudio (instead of spice ->
> > spice-gtk -> pulseaudio).
> 
> I didn't know how I'm supposed to do that the first time I saw this comment,
> but since I'm checking again, I decided to give it a try.
> 
> The QEMU_AUDIO_DRV=pa looks like an environment variable, so I did this:
> $ export QEMU_AUDIO_DRV=pa
> $ qemu-kvm -drive file=win7.qcow2,if=virtio,cache=unsafe -net
> nic,model=virtio,macaddr=52:54:00:66:cd:e8 -net bridge,br=virbr0 -usbdevice
> tablet -m 2048 -smp 2 -vga qxl -soundhw hda -spice
> port=5900,ipv4,password=123456 -display none
> 
> I didn't use -playback-compression=off switch in the above qemu cmdline
> options so the sound should be bad. But now with the QEMU_AUDIO_DRV=pa, the
> quality is pretty good. So I would say this environment variable setting
> also fixed the sound quality problem, thanks!

Aha, so I was wrong at comment #14 - This is really a Spice bug.

(In reply to Aaron Lu from comment #23)
> Just realized that bypassing spice also means no sound output when
> connecting the VM through another machine...

Yes, bypassing with Spice only make sense if the host machine and client machine are the same. This was just a test to check if bug is on Spice or in QEMU.

I'll change the component for now.
Thanks for testing

So qemu defaults to playback-compression. Is spice server smart enough to turn that off if the user passes in a file descriptor via qemu add_client/virDomainOpenGraphics ?

Also, would be nice if playback-compression could be disabled client side, like can be done for image compression via preferred-compression. It would be nice if tools like virt-manager/boxes could disable these optimizations when we know we are talking to a local VM, but use the VM/qemu defaults otherwise

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

At least the playback-compression app issues are still relevant AFAIK, so moving to f25, but maybe the quality issues are fixed. Needs someone from spice to chime in

I am having the problem on Fedora 25 too: with a Windows 8.1 64-bit installation, as well as Windows 10 64-bit installation.  I use the ICH6 device, and the audio is very clicky, with multiple clicks per second.

The OS's driver is set to 44100 Hz, and changing this has no effect on the clicks.

Using AC97 device as per the above comment, my audio is almost perfect but nobody on a conference call can hear me because my mic is incredibly soft!  Even after checking "Mic Boost" in the guest and pushing the levels, not much changed.  

My question: how can I implement the environment variable setting
(export QEMU_AUDIO_DRV=pa)
when I start and view my VM's from virt-manager?

Running:
export QEMU_AUDIO_DRV=pa ; virt-manager
from a shell with my user account doesn't help much, and when I look at the VM process it runs as the "qemu" user, which is a "nologin" account, so I can't su to it.

What am I missing?

This bug is very likely to be the same as Bug 1203507 (on RHEL7) see comment 21 and 22 there for the tests that I have done and the explanation of the issue in comment 23

(In reply to Louis van Dyk from comment #28)
> My question: how can I implement the environment variable setting
> (export QEMU_AUDIO_DRV=pa)
> when I start and view my VM's from virt-manager?
> 
> Running:
> export QEMU_AUDIO_DRV=pa ; virt-manager
> from a shell with my user account doesn't help much, and when I look at the
> VM process it runs as the "qemu" user, which is a "nologin" account, so I
> can't su to it.
> 
> What am I missing?

You will need to edit the VM's domain, like virsh edit <domain> for that.
Something like this [0] should help you but I'm not sure it'll help.

[0] http://blog.vmsplice.net/2011/04/how-to-pass-qemu-command-line-options.html

Thanks!

Based on your response: am I adding the QEMU_AUDIO_DRV=pa or the playback-compression=off options?

No luck:

First edited with virsh and changed
<domain type='kvm'>
to
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
then added in 
  <qemu:commandline>
    <qemu:env name='QEMU_AUDIO_DRV' value='pa'/>
  </qemu:commandline>
It doesn't really matter where, as virsh places it just before the final
</domain>
line.

This didn't change the audio clicking.

So, secondly, I removed the above additions, and added the playback compression inside the graphics tags.
    <graphics type='spice' autoport='yes'>
      <listen type='address'/>
      <playback compression='off'/>
    </graphics>

Sadly this too has not helped.

(In reply to Louis van Dyk from comment #31)
> Sadly this too has not helped.

Thanks for the feedback. Yes, the problem seems to lay on the audio device (ich6). I would use ac97 for now and open a bug for the microphone. Let me know the bug number if do that, I'll take a look.

Based on comment 31, this does look like Bug 1203507 where the ich6 device seems to play the audio slower then necessary. Comment 18 states the same (ich6 bad, ac97 okay).

RHEL7 bug might be fixed first so I'm marking the dependency for now.

I'm using ICH sound device with '-soundhw hda' and together '-spice port=5910,ipv4,password=xxx,playback-compression=off', the sound quality is good.

I'm not familiar with virsh or virtmanager on how to edit the guest cmdline options but there is a '-' between 'playback' and 'compression' that is missing in Louis' config as posted in comment #31. Not sure if that is the reason why sound is still bad for him. I think this can be verified after you launched the guest with 'ps ax' and check what exactly the cmdline options are passed to qemu.

Ah, Aaron ... just as I got excited!  

virsh edits the xml file, but only accepts it with a space between playback and compression.  When I start the VM the ps line shows:

-spice port=5900,addr=127.0.0.1,disable-ticketing,playback-compression=on,seamless-migration=on 

@Victor: I tested AC97 again, and the Mic is definitely very soft.  I will log a ticket for that.

I have used Skype in a Windows 7 x64 VM with AC97 sound device in Fedora 26.

Sound output is passable with some minor static.

Sound input is OK with no microphone issues noticed in the Skype test call or in conversations with others.

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The problem is still there on Fedora 27: when spice is used, if I do not pass "playback-compression=off" to spice, sound quality is bad.

Note there's been some patches that will be in qemu 3.0 that apparently massively improve audio quality with windows and the hda/ich6/ich9 sound device, so that's something to try eventually.

This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.