audio: fix bug 1858488
commitfdc8c5f4717f42f4b19b733ada30da2ba92a3ad1
authorVolker Rümelin <vr_qemu@t-online.de>
Thu, 23 Jan 2020 07:49:39 +0000 (23 08:49 +0100)
committerGerd Hoffmann <kraxel@redhat.com>
Fri, 31 Jan 2020 07:48:03 +0000 (31 08:48 +0100)
tree96e70e508afb0631a2f107f6e7a21a07eddc53e6
parent69ac07863205ec281bcd2f2e6571202da0c315f7
audio: fix bug 1858488

The combined generic buffer management code and buffer run out
code in function audio_generic_put_buffer_out has a problematic
behaviour. A few hundred milliseconds after playback starts the
mixing buffer and the generic buffer are nearly full and the
following pattern can be seen.

On first call of audio_pcm_hw_run_out the buffer run code in
audio_generic_put_buffer_out writes some data to the audio
hardware but the generic buffer will fill faster and is full
when audio_pcm_hw_run_out returns. This is because emulated
audio devices can produce playback data at a higher rate than
the audio backend hardware consumes this data.

On next call of audio_pcm_hw_run_out the buffer run code in
audio_generic_put_buffer_out writes some data to the audio
hardware but no audio data is transferred to the generic buffer
because the buffer is already full.

Then the pattern repeats. For the emulated audio device this
looks like the audio timer period has doubled.

This patch splits the combined generic buffer management code
and buffer run out code and calls the buffer run out code after
buffer management code to break this pattern.

The bug report is for the wav audio backend. But the problem is
not limited to this backend. All audio backends which use the
audio_generic_put_buffer_out function show this problem.

Buglink: https://bugs.launchpad.net/qemu/+bug/1858488
Signed-off-by: Volker Rümelin <vr_qemu@t-online.de>
Message-Id: <20200123074943.6699-5-vr_qemu@t-online.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
audio/alsaaudio.c
audio/audio.c
audio/audio_int.h
audio/coreaudio.c
audio/noaudio.c
audio/ossaudio.c
audio/sdlaudio.c
audio/wavaudio.c