Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1176761 - Windows7 guest sound quality is bad
Windows7 guest sound quality is bad
Status: NEW
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
27
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Fedora Virtualization Maintainers
Fedora Extras Quality Assurance
:
Depends On: 1203507
Blocks:
  Show dependency treegraph
 
Reported: 2014-12-23 00:16 EST by Aaron Lu
Modified: 2018-07-31 12:02 EDT (History)
30 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Aaron Lu 2014-12-23 00:16:04 EST
Description of problem:
After upgrade to Fedora 21 from Fedora 20, the Windows7 guest's sound quality became a lot worse. The sound is not as continuous as before with some noise from time to time. The default sound device ich6 is used.

Version-Release number of selected component (if applicable):
$ rpm -qa |grep virt
libvirt-glib-0.1.9-1.fc21.x86_64
libvirt-daemon-1.2.9.1-2.fc21.x86_64
libvirt-daemon-driver-interface-1.2.9.1-2.fc21.x86_64
libvirt-daemon-driver-storage-1.2.9.1-2.fc21.x86_64
virt-manager-1.1.0-4.git310f6527.fc21.noarch
libvirt-client-1.2.9.1-2.fc21.x86_64
libvirt-daemon-driver-qemu-1.2.9.1-2.fc21.x86_64
libvirt-daemon-driver-nodedev-1.2.9.1-2.fc21.x86_64
libgovirt-0.3.2-1.fc21.x86_64
libvirt-daemon-kvm-1.2.9.1-2.fc21.x86_64
libvirt-python-1.2.9-1.fc21.x86_64
libvirt-daemon-driver-secret-1.2.9.1-2.fc21.x86_64
virt-viewer-1.0-2.fc21.x86_64
libvirt-daemon-config-network-1.2.9.1-2.fc21.x86_64
libvirt-daemon-driver-nwfilter-1.2.9.1-2.fc21.x86_64
virt-install-1.1.0-4.git310f6527.fc21.noarch
libvirt-daemon-driver-network-1.2.9.1-2.fc21.x86_64
virt-manager-common-1.1.0-4.git310f6527.fc21.noarch
$ rpm -qa |grep qemu
ipxe-roms-qemu-20140303-3.gitff1e7fc7.fc21.noarch
qemu-img-2.1.2-7.fc21.x86_64
qemu-common-2.1.2-7.fc21.x86_64
libvirt-daemon-driver-qemu-1.2.9.1-2.fc21.x86_64
qemu-system-x86-2.1.2-7.fc21.x86_64
qemu-kvm-2.1.2-7.fc21.x86_64


How reproducible:
Always

Steps to Reproduce:
1. Start Win7 guest
2. 
3.

Actual results:
Sound quality is bad

Expected results:
Sound quality is good

Additional info:
Comment 1 Aaron Lu 2014-12-23 00:28:16 EST
BTW, there is no problem when playing a song on the host system with the USB headset.
Comment 2 Victor Toso 2014-12-23 05:40:32 EST
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
Comment 3 Aaron Lu 2014-12-24 01:11:30 EST
Thanks for the info, please keep me updated if there is a fix.
Comment 4 Aaron Lu 2015-05-04 05:04:40 EDT
A workaround is to pass through the USB controller where my USB headset is attached and it works much better.
Comment 5 Aaron Lu 2015-05-04 05:14:00 EDT
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.
Comment 6 Cole Robinson 2015-05-06 11:03:48 EDT
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?
Comment 7 Aaron Lu 2015-05-07 05:18:03 EDT
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
Comment 8 Marc-Andre Lureau 2015-05-07 09:10:24 EDT
(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.
Comment 9 Aaron Lu 2015-05-12 01:23:30 EDT
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.
Comment 10 Aaron Lu 2015-05-12 01:40:13 EDT
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.
Comment 11 Aaron Lu 2015-05-12 02:36:45 EDT
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
Comment 12 Victor Toso 2015-06-04 05:25:11 EDT
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;
Comment 13 Victor Toso 2015-06-12 10:51:13 EDT
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.
Comment 14 Victor Toso 2015-06-15 11:47:16 EDT
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.
Comment 15 Aaron Lu 2015-06-18 22:49:20 EDT
(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.
Comment 16 Christian Affolter 2015-07-07 18:42:24 EDT
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
Comment 17 Aaron Lu 2015-07-07 21:46:29 EDT
(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!
Comment 18 edgar 2015-07-29 21:53:09 EDT
(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.
Comment 19 Fedora End Of Life 2015-11-04 06:00:12 EST
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.
Comment 20 Cole Robinson 2015-11-04 18:32:55 EST
Are people still hitting these issues with fedora 22 or later? If so please adjust the bug version
Comment 21 Aaron Lu 2015-11-04 20:46:56 EST
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?
Comment 22 Aaron Lu 2015-11-04 21:06:38 EST
(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!
Comment 23 Aaron Lu 2015-11-04 21:19:34 EST
Just realized that bypassing spice also means no sound output when connecting the VM through another machine...
Comment 24 Victor Toso 2015-11-05 01:55:43 EST
(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
Comment 25 Cole Robinson 2016-05-07 19:56:37 EDT
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
Comment 26 Fedora End Of Life 2016-11-24 06:20:42 EST
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.
Comment 27 Cole Robinson 2016-12-12 15:51:23 EST
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
Comment 28 Louis van Dyk 2017-03-30 06:51:00 EDT
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?
Comment 29 Victor Toso 2017-03-30 07:17:29 EDT
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
Comment 30 Louis van Dyk 2017-03-30 09:24:36 EDT
Thanks!

Based on your response: am I adding the QEMU_AUDIO_DRV=pa or the playback-compression=off options?
Comment 31 Louis van Dyk 2017-03-30 09:55:24 EDT
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.
Comment 32 Victor Toso 2017-03-30 10:15:14 EDT
(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.
Comment 33 Victor Toso 2017-03-30 10:18:46 EDT
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.
Comment 34 Aaron Lu 2017-03-30 21:52:27 EDT
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.
Comment 35 Louis van Dyk 2017-03-31 06:12:24 EDT
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.
Comment 36 Aram Agajanian 2017-08-11 07:45:30 EDT
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.
Comment 37 Fedora End Of Life 2017-11-16 14:46:35 EST
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.
Comment 38 Aaron Lu 2017-11-16 20:52:11 EST
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.
Comment 39 Cole Robinson 2018-07-31 12:02:29 EDT
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.

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