[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 19/25] paaudio: fix playback glitches

From: Kővágó Zoltán
Subject: Re: [Qemu-devel] [PATCH 19/25] paaudio: fix playback glitches
Date: Fri, 21 Aug 2015 15:18:10 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

2015-08-21 00:08 keltezéssel, Marc-André Lureau írta:

On Thu, Aug 6, 2015 at 8:28 PM, Kővágó, Zoltán <address@hidden> wrote:
Pulseaudio normally assumes that when the server wants it, the client
can generate the audio samples and send it right away.  Unfortunately
this is not the case with QEMU -- it's up to the emulated system when
does it generate the samples.  Buffering the samples and sending them
from a background thread is just a workaround, that doesn't work too
well.  Instead enable pa's compatibility support and let pa worry about
the details.

Afaik, it's not a problem if the audio data is not available right
away (live sources): PulseAudio should deal with that. I think it will
simply silence and wait (but it could actually be smarter than that?)

Yes, it will simply silence and wait, until more data arrives. The problem is that thing happens, like 10 times each second. (If I watch pacmd list-sink-inputs, I can see that status quickly varies between drained and running, while playing an audio file in the guest)

PA_STREAM_EARLY_REQUESTS is going to make PA request data more
frequently (every minreq). I don't get why that would help here. It's
meant for bad behaving applications using usleep and such that aren't
fixable, not a solution for audio glitches.

The problem is that normally pulseaudio sends requests for data very late -- assuming that the application will quickly generate the required samples and send them back. The problem is that the audio subsystem only "runs" each 10 ms, so it may take up to 10ms until qemu sends back data after the request, which is apparently too much. With PA_STREAM_EARLY_REQUEST pulseaudio will request data as soon as it has enough free space in it's buffer, and not wait until the last moment.

Maybe tweaking pa buffer settings would help too, I'm not sure. And yes, qemu is pretty much a bad behaving application that, while not using usleep directly, only produces audio every 10ms (by default).

If qemu produces too much data than what PA can consume, it should
drop the old data, and only play current audio (unfortunately, that
doesn't seem to be the case looking at audio_pcm_sw_write). If qemu
produces too little, it can still write whatever it has when it has

Could you provide a way to reproduce the glitch you experience or
explain more clearly how this flag helps?

It happens for me with a pretty much a default pulseaudio configuration, even with the stable release. For example day24 from last year qemu advent calendar with pulseaudio backend. (Sometimes it fixes itself after some time, very rarely it work normally, but most cases I just get that constant buffer underflow.)


Signed-off-by: Kővágó, Zoltán <address@hidden>
  audio/paaudio.c | 6 ++----
  1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/audio/paaudio.c b/audio/paaudio.c
index 2aee22f..3990a80 100644
--- a/audio/paaudio.c
+++ b/audio/paaudio.c
@@ -510,10 +510,8 @@ static pa_stream *qpa_simple_new (

      flags =
      if (dev) {
          /* don't move the stream if the user specified a sink/source */
          flags |= PA_STREAM_DONT_MOVE;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]