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

[Kővágó Zoltán]

2015-08-21 00:08 keltezéssel, Marc-André Lureau írta:
> Hi
>
> 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
> it.
>
> 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.)

> thanks
>
> > 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 =
> >           PA_STREAM_INTERPOLATE_TIMING
> > -#ifdef PA_STREAM_ADJUST_LATENCY
> > -        |PA_STREAM_ADJUST_LATENCY
> > -#endif
> > -        |PA_STREAM_AUTO_TIMING_UPDATE;
> > +        |PA_STREAM_AUTO_TIMING_UPDATE
> > +        |PA_STREAM_EARLY_REQUESTS;
> >       if (dev) {
> >           /* don't move the stream if the user specified a sink/source */
> >           flags |= PA_STREAM_DONT_MOVE;
> > --
> > 2.4.5