I can hear small glitches when playing audio with Windows 7 as guest with intel-hda so I would like to confirm if this is the problem you have.

If not, what do you mean exactly by the audio not being fluent? Do you hear something else or does it stop playing? Could you please enable debug with SPICE_DEBUG=1 and attach it?

Forgot to add needinfo

(In reply to Victor Toso from comment #2)
> I can hear small glitches when playing audio with Windows 7 as guest with
> intel-hda so I would like to confirm if this is the problem you have.
> 

Yes,you are right.There are some small glitches, it does not stop playing.


> If not, what do you mean exactly by the audio not being fluent? Do you hear
> something else or does it stop playing? Could you please enable debug with
> SPICE_DEBUG=1 and attach it?
I will try it with SPICE_DEBUG=1.

Created attachment 1016669 [details]
spice debug info

(In reply to Victor Toso from comment #2)
> I can hear small glitches when playing audio with Windows 7 as guest with
> intel-hda so I would like to confirm if this is the problem you have.
> 
> If not, what do you mean exactly by the audio not being fluent? Do you hear
> something else or does it stop playing? Could you please enable debug with
> SPICE_DEBUG=1 and attach it?

I have obtained the spice debug info via "remote-viewer spice://localhost:5910 --spice-debug", and attached it.

Running the playback with gstreamer backend and GST_DEBUG=3, you can easily spot the client underflows. It's interesting to notice that this doesn't occur much with a linux guest. It looks like buffering on windows is much shorter or some timing issue. I don't know if it's something that can be tweaked on qemu side. If not, I think the server or client will need to do more buffering, but this will still produce underrun anyway, so it must be solved at the audio source.

Furthermore, running qemu with wav backend exhibits samilar glitches

I notice that hda xfer and spice encoding are done in the same main thread, driven by audio_timer(). I don't have enough knowldge of hda & timing but this may be a hint.. moving to qemu

I have the same problem and I have reported bug #1176761. Currently, I can work around this problem by invoking qemu with the following cmdline options:
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

As suggested in comment #7 this looks a regression in QEMU. I've tested with older versions of QEMU and you still can hit audio problems on v2.0.0 but not in v1.7.2.

As per comment #8, bug #1176761 is the same of this one (but on Fedora).
Moving both bugs to QEMU.

(In reply to Marc-Andre Lureau from comment #7)
> Running the playback with gstreamer backend and GST_DEBUG=3, you can easily
> spot the client underflows. It's interesting to notice that this doesn't
> occur much with a linux guest. It looks like buffering on windows is much
> shorter or some timing issue.

Windows uses *much* smaller buffers.  Which makes the whole very sensitive to latency problems (anywhere in qemu).

> I don't know if it's something that can be
> tweaked on qemu side. If not, I think the server or client will need to do
> more buffering, but this will still produce underrun anyway, so it must be
> solved at the audio source.

More buffering will not help at all.  Underruns happen in case we are not able to raise the sound card irq at the required rate so the windows guest can't fill the sound buffers in time.

Dunno whenever the sound buffer size can be tweaked at the guest side somehow.
There seems to be some obscure registry entry for pretty much anything in windows ;)

(In reply to Aaron Lu from comment #8)
> I have the same problem and I have reported bug #1176761. Currently, I can
> work around this problem by invoking qemu with the following cmdline options:
> 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

What command line change breaks things?

It's been some time, all I can recall is that the virt-manager use sound compression by default and in my above cmdline, I didn't use that.

So, if you add playback-compression=off to -spice, does that change anything?

The sound quality is good with this config(I used virsh edit win7):

    <graphics type='spice' autoport='yes' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
      <playback compression='off'/>
    </graphics>

and if I remove the "<playback compression='off'/>" line(as is the default case), the sound quality becomes bad.

(In reply to Gerd Hoffmann from comment #11)
> (In reply to Aaron Lu from comment #8)
> > I have the same problem and I have reported bug #1176761. Currently, I can
> > work around this problem by invoking qemu with the following cmdline options:
> > 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
> 
> What command line change breaks things?

Oh I remembered, the above cmdline doesn't make use of spice so it doesn't have problem.

Summary:
1 If I do not use spice, no problem with sound;
2 If I use spice(the windows guest created with virt-manager makes use of spice by default), I need to pass the 'playback_compression=off' to spice to get a much better sound quality(it's almost as good as the no-spice case).

(In reply to Gerd Hoffmann from comment #13)
> So, if you add playback-compression=off to -spice, does that change anything?

when I add playback-compression=off to -spice, I still can hear small glitches.
I used the qemu command line in Description.

(In reply to Yanhui Ma from comment #17)
> (In reply to Gerd Hoffmann from comment #13)
> > So, if you add playback-compression=off to -spice, does that change anything?
> 
> when I add playback-compression=off to -spice, I still can hear small
> glitches.
> I used the qemu command line in Description.

We need some guidance from the Spice team here on what to do.

(In reply to Ademar Reis from comment #20)
> We need some guidance from the Spice team here on what to do.

As per comment #7 - this seems to be in host/guest as it is reproducible without Spice. I also tested with different QEMU versions (comment #9) and it seems that this issue did not happen on 1.7.2 version.

I also mentioned the `audio overflow` email before [0], not sure if it could be related to this issue.

[0] http://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg01835.html

Tracking this issue is not easy but I don't think its a buffer issue on spice side...

A possible hint is the frequency used. If *force* [1] decoding with 44100, problem is gone.

[1]
diff --git a/src/spice-pulse.c b/src/spice-pulse.c
index 5248bc3..2b4a4ef 100644
--- a/src/spice-pulse.c
+++ b/src/spice-pulse.c
@@ -409,7 +409,7 @@ static void playback_start(SpicePlaybackChannel *channel, gint format, gint chan
 
     g_return_if_fail(format == SPICE_AUDIO_FMT_S16);
     p->playback.spec.format   = PA_SAMPLE_S16LE;
-    p->playback.spec.rate     = frequency;
+    p->playback.spec.rate     = 44100; /* frequency;*/
     p->playback.spec.channels = channels;
     p->target_delay = latency;
     p->last_delay = 0;

A little bit more info..

This seems to be hda bug in QEMU. I can't hear any glitches with ac97.

The mapping between guest and QEMU seems correct (48kHz) but if I force 44.1kHz on QEMU while guest is set to 48kHz, no more glitches...

diff --git a/hw/audio/hda-codec.c b/hw/audio/hda-codec.c
index 52d4640..a9362ec 100644
--- a/hw/audio/hda-codec.c
+++ b/hw/audio/hda-codec.c
@@ -97,6 +97,9 @@ static void hda_codec_parse_fmt(uint32_t format, struct audsettings *as)
     case 7: as->freq /= 8; break;
     }
 
+    /* FIXME: Just for testing */
+    as->freq = 44100;
+
     switch (format & AC_FMT_BITS_MASK) {
     case AC_FMT_BITS_8:  as->fmt = AUD_FMT_S8;  break;
     case AC_FMT_BITS_16: as->fmt = AUD_FMT_S16; break;

Maybe some bit that needs to be shifted?

I guess Gerd can point it out...

(In reply to Victor Toso from comment #22)
> A little bit more info..
> 
> This seems to be hda bug in QEMU. I can't hear any glitches with ac97.
> 
> The mapping between guest and QEMU seems correct (48kHz) but if I force
> 44.1kHz on QEMU while guest is set to 48kHz, no more glitches...
> 
> diff --git a/hw/audio/hda-codec.c b/hw/audio/hda-codec.c
> index 52d4640..a9362ec 100644
> --- a/hw/audio/hda-codec.c
> +++ b/hw/audio/hda-codec.c
> @@ -97,6 +97,9 @@ static void hda_codec_parse_fmt(uint32_t format, struct
> audsettings *as)
>      case 7: as->freq /= 8; break;
>      }
>  
> +    /* FIXME: Just for testing */
> +    as->freq = 44100;
> +
>      switch (format & AC_FMT_BITS_MASK) {
>      case AC_FMT_BITS_8:  as->fmt = AUD_FMT_S8;  break;
>      case AC_FMT_BITS_16: as->fmt = AUD_FMT_S16; break;
> 
> Maybe some bit that needs to be shifted?
> 
> I guess Gerd can point it out...

So we are playing the sound a bit slower than it should be played.  That'll fill the buffers in the output pipeline, which papers over the latency issues.  But you can also probably hear the effect when listening carefully.  Also when watching videos I suspect they will not be lip-sync any more.

That things are working fine on ac97 can also be guest driver related.  We have the same with hda when comparing windows and linux:  The windows driver uses _much_ smaller buffers, which in turn makes windows guests _much_ more sensitive to latency issues (anywhere in qemu) when playing sound.

I'm running into similar issues trying to run skype in a windows 10 guest.  <playback compression='off'\> does not appear to help me much.  ac97 does not appear to be an option with win10.  With ich9 microphone sound appears to be much worse than with ich6.

Is there a way to get sound without spice while still using libvirtd/virt-viewer?

(In reply to Orion Poplawski from comment #24)
> I'm running into similar issues trying to run skype in a windows 10 guest. 
> <playback compression='off'\> does not appear to help me much.  ac97 does
> not appear to be an option with win10.  With ich9 microphone sound appears
> to be much worse than with ich6.
> 
> Is there a way to get sound without spice while still using
> libvirtd/virt-viewer?

Hi Orion.

I don't know the answer to your question, but if this issue is critical or in any way time sensitive to you or your organization, please raise a ticket through your regular Red Hat support channels to make certain it receives the proper attention and prioritization.

For information on how to contact the Red Hat production support team, please visit: https://www.redhat.com/support/process/production/#howto

I am also having this issue, it really isn't fixed by AC97, just mitigated to the point where most people wont really notice it. Also I don't think it is a valid fix to rely on emulating deprecated hardware. Let's get audio emulation in qemu fixed, I'm happy to help where I can but I don't have the background to fix it myself.

One can try to workaround this QEMU issue by disabling OPUS back-end in spice client to force playback audio to 44100 with SPICE_DISABLE_OPUS=1 remote-viewer ...

Victor, 

While that might help some people it isn't the root cause of the problem. All the documented "solutions" to this issue are just hacks that are very hit and miss, in the best case they aren't really fixing the problem just making it less noticeable. In my case, for example, I am not using OPUS nor spice, so this will have no effect on me, there is something fundamentally broken with the way audio is being handled by qemu (or something else in the virtualization stack). This fundamental flaw is what needs fixing.

I think one thing should be easy to understand and would help. Is Qemu sending the right samples? If Qemu is saying 44.1K and sending 48K samples per second or vice versa is a Qemu problem causing glitches, if is sending the right rate then the issue must be in Spice (a wrong buffer management, wrong latency handling, too much cpu/time compressing or so on).

Ok, Qemu is sending 46K of samples with a 48K setting.

Setting QEMU_AUDIO_TIMER_PERIOD to 200 (default is 100) is achieving the exact 48K for me. Note that more CPU usage is expected. For some reasons it seems the Qemu code is polling the audio data. Didn't spend much to follow all the path.

This frequency was changed by this patch


commit 40a814b0b1789b94c483190b3208729b5182e5bd
Author: Hans de Goede <hdegoede>
Date:   Wed Oct 9 21:38:32 2013 +0200

    audio: Lower default wakeup rate to 100 times / second

    This is more then plenty to keep audio card fifos filles / emptied.

    This drops host cpu-load for audio playback inside a linux vm from
    13% to 9%.

    Signed-off-by: Hans de Goede <hdegoede>
    Signed-off-by: Gerd Hoffmann <kraxel>


from 250 to 100 Hz. Apparently for Windows is not enough.

Nice detective work

However, I still had audible clicks. I use https://www.youtube.com/watch?v=2ZrWHtvSog4 for my audio test, which I confirm several times works without artifacts on the host system.

Here is what I tried:

I use a dell soundbar, which operates at 48khz, as the speaker. My windows is set to operate at 48khz as well and the emulated hardware is ich9. Note that I do not use spice, qemu talks directly  to my audio stack, so at least what I am seeing is not a spice issue.

I tested using the alsa driver and talking directly to the hardware device.

For Scenario 1, I used the following settings:

    <qemu:env name='QEMU_AUDIO_DRV' value='alsa'/>
    <qemu:env name='QEMU_ALSA_DAC_DEV' value='iec958:CARD=SoundBar,DEV=0'/>
    <qemu:env name='QEMU_AUDIO_DAC_FIXED_FREQ' value='48000'/>
    <qemu:env name='QEMU_AUDIO_TIMER_PERIOD' value='200'/>

The audio sounds terrible, barely recognizable through all the noise and the synchronization is way off.

For Scenario 2, With my standard settings and only the timer period changed:

    <qemu:env name='QEMU_AUDIO_DRV' value='alsa'/>
    <qemu:env name='QEMU_ALSA_DAC_DEV' value='iec958:CARD=SoundBar,DEV=0'/>
    <qemu:env name='QEMU_AUDIO_DAC_FIXED_FREQ' value='48000'/>
    <qemu:env name='QEMU_ALSA_DAC_PERIOD_SIZE' value='0'/>
    <qemu:env name='QEMU_ALSA_DAC_SIZE_IN_USEC' value='0'/>
    <qemu:env name='QEMU_ALSA_DAC_BUFFER_SIZE' value='4096'/>
    <qemu:env name='QEMU_AUDIO_TIMER_PERIOD' value='200'/>
    <qemu:env name='QEMU_AUDIO_DAC_FIXED_SETTINGS' value='0'/>

The audio quality is correct with the rare click or pop artifact. Sync is dead on.

At this point I removed a single env variable at a time until I could reproduce the noise from Scenerio 1 to try to tie it to a single setting. This turned out to not be the simple answer I expected. It seems that I need both of 

    <qemu:env name='QEMU_ALSA_DAC_PERIOD_SIZE' value='0'/>
    <qemu:env name='QEMU_ALSA_DAC_SIZE_IN_USEC' value='0'/>

as well as one of

<qemu:env name='QEMU_ALSA_DAC_BUFFER_SIZE' value='4096'/>

or

<qemu:env name='QEMU_AUDIO_DAC_FIXED_SETTINGS' value='0'/>

to avoid the noise. I assume I knew this at some point which is why I had it configured the way  I did but it's been a while since I made this configuration.

Next I tested pulseaudio using this following settings (Scenario 3)

    <qemu:env name='QEMU_AUDIO_DRV' value='pa'/>
    <qemu:env name='QEMU_PA_SERVER' value='/run/user/1000/pulse/native'/>
    <qemu:env name='QEMU_AUDIO_DAC_FIXED_FREQ' value='48000'/>
    <qemu:env name='QEMU_AUDIO_TIMER_PERIOD' value='200'/>

This resulted in horrible noise again and the sync was way off. 

Adding in 

    <qemu:env name='QEMU_AUDIO_DAC_FIXED_SETTINGS' value='0'/> 

didnt help. Because pulseaudio may not be expecting 48khz, I reverted to Scenario 3 and tested with everything set up for 44.1khz. This also sounds awful. 

So to summarize, the best settings I found were my original settings with the timer period upped to 200 (though I am not entirely sure thats helping at all), and it still doesn't definitively solve the problem (not that I expected it to or anything, I really think something is fundamentally wrong here).

Lastly, you had made a comment about qemu doing some polling. There is an option 

QEMU_AUDIO_DAC_TRY_POLL: boolean, default = 1
    Attempt using poll mode for DAC

that may be related to what you are talking about. When I set this to 0 using my "vetted" setting, I hear more pops than with it set to 1. I hope this information is useful somehow

About polling I was referring to the Qemu code. I didn't dig much into all the sound code path but it sounds weird to me that there's a "tick" (the QEMU_AUDIO_TIMER_PERIOD at the end set this tick) basically polling for sound data. I mean, as far as I know all sound cards are emulated so we could run the code when the guest is writing data or when the sound interrupt is triggered and should not be influenced by this tick. Also the tick should depends in the buffer size used and sound frequency, not a fixed value.

To exclude the Spice problem I just replace the code that was getting data from Qemu (in my case spice_server_playback_put_samples) with some debugging printing time and samples received:

+
+    static uint64_t got_samples = 0, got_samples_print = 0;
+    got_samples += frame->num_samples;
+    if (got_samples >= got_samples_print) {
+        spice_warning("SAMPLES %lu %lu", spice_get_monotonic_time_ns(), got_samples);
+        got_samples_print += 1000000;
+    }
+

this way I managed to compute the samples received which should (on average) match the frequency (samples2-samples1)/(time2-time1 in seconds). This way I detected that Qemu itself was loosing samples. You can probably do the same with alsa/pulseaudio to see if your problem is this. Another stuff you can try is to save the audio to a wav file. There are some sound options to do that. Once you do have the wav you can check if there are gliches in the sound. This and the check that you are not loosing samples (formula above) should exclude buffer issues. The problems left are latencies and interactions with sound libraries (alsa/pulseaudio/oss/whatever). Consider that latencies can be affected by machine load, maybe the sound libraries are expecting to receive data without much delays.

For machine load: I definitely notice a correlation, less host CPU time available => more pops in VM audio. Still I'm surprised that it's so bad. One thing that might be worth experimenting with is seeing how host only audio does when the host is under high CPU load

When I rollback commit 40a814b0b1789b94c483190b3208729b5182e5bd, the glitches becomes very weak, but when watching videos continuously, I suspect they will not be lip-sync any more and audio sounds slow. Can anyone resolve this problems?

(In reply to yueyihua from comment #35)
> When I rollback commit 40a814b0b1789b94c483190b3208729b5182e5bd

For the record, this is
https://git.qemu.org/?p=qemu.git;a=commit;h=40a814b0b1789b94c483190b3208729b5182e5bd
"audio: Lower default wakeup rate to 100 times / second"

(In reply to Christophe Fergeau from comment #36)
> (In reply to yueyihua from comment #35)
> > When I rollback commit 40a814b0b1789b94c483190b3208729b5182e5bd
> 
> For the record, this is
> https://git.qemu.org/?p=qemu.git;a=commit;
> h=40a814b0b1789b94c483190b3208729b5182e5bd
> "audio: Lower default wakeup rate to 100 times / second"

I know this is the real reason, but after I changed this default hertz to 250, and playing videos, I suspect that they will not be lip-sync any more and audio sounds slow. I really don't know why, is spice can resolve it?

If I use ac97 sound card, I hear no more glitches, but when watching videos continuously, I still suspect not be lip-sync any more and audio sounds slow, But if I reconnect the VM with spice-gtk, I found they are lip-sync. Maybe this information is useful.

Test builds available from:

https://people.redhat.com/ghoffman/bz1203507/

Feedback welcome.

I'd like to try your test builds under Fedora.
As of Fedora 28, kernel 4.17.19-200.fc28.x86_64, these errors appear when attempting the update:

dnf update
test-rpms-bz1203507                                                                                 187 kB/s |  43 kB     00:00    
Last metadata expiration check: 0:00:00 ago on Mon 03 Sep 2018 09:33:27 AM CDT.
Dependencies resolved.

 Problem 1: cannot install the best update candidate for package qemu-img-2:2.11.2-2.fc28.x86_64
  - nothing provides libgcrypt.so.11()(64bit) needed by qemu-img-rhev-10:2.12.0-5.el7.bz1203507.7.x86_64
 Problem 2: cannot install the best update candidate for package qemu-kvm-2:2.11.2-2.fc28.x86_64
  - nothing provides libgcrypt.so.11()(64bit) needed by qemu-kvm-rhev-10:2.12.0-5.el7.bz1203507.7.x86_64
====================================================================================================================================
 Package                     Arch                 Version                                   Repository                         Size
====================================================================================================================================
Skipping packages with broken dependencies:
 qemu-img-rhev               x86_64               10:2.12.0-5.el7.bz1203507.7               test-rpms-bz1203507               1.3 M
 qemu-kvm-rhev               x86_64               10:2.12.0-5.el7.bz1203507.7               test-rpms-bz1203507               3.4 M

(In reply to Hugh Sparks from comment #40)
> I'd like to try your test builds under Fedora.

It's a RHEL-7 build, so that isn't going to fly.

You can check whenever virt-preview[1] has qemu 3.0 builds (it should have) and test whenever this improves things.  When using libvirt make sure you use a 3.0 machine type, otherwise hda runs in compatibility mode and nothing will change.

[1] https://fedoraproject.org/wiki/Virtualization_Preview_Repository

What's a 3.0 machine type? Are we talking Q35 or cpu type? How do I know if HDA is in compat mode?

Today, Fedora 29 now comes with 3.0.0 FYI

pc/q35 ("qemu-kvm -M help" lists them all).

In libvirt xml:

<type arch='x86_64' machine='pc-q35-2.9'>hvm</type>
                                    ^^^ this is the version

Make sure the version is 3.0 (or newer), otherwise hda goes into compat mode.

Using:

     <type arch='x86_64' machine='pc-q35-3.0'>hvm</type>

and:

     <graphics type='spice' autoport='yes'>
       <listen type='address'/>
       <image compression='off'/>
       <playback compression='off'/>
       <gl enable='no' rendernode='/dev/dri/by-path/pci-0000:00:02.0-render'/>
     </graphics>

On Windows 10 with "16 bit, 48000 Hz" in the guest or "16 bit, 41000 Hz" 

Does not resolve the issue. Seems anecdotally a little better, but still when any meaningful load is put on the system regardless of context (inside or out) the crackling resumes. 

Most notably it seems to be very reproducible via the Playback -> Properties ->  Advanced [ Test ] button 

The right channel is the one that seems to crackle every time, I suspect not because it's the right channel but because it's just long enough when it reaches the right channel to have something to do with buffering.

Post the test result to Gerd and looks like the bug has been fixed, mark as verified

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:1293