aboutsummaryrefslogtreecommitdiff
path: root/.editorconfig
diff options
context:
space:
mode:
authorVolker RĂ¼melin <vr_qemu@t-online.de>2020-01-23 08:49:39 +0100
committerGerd Hoffmann <kraxel@redhat.com>2020-01-31 08:48:03 +0100
commitfdc8c5f4717f42f4b19b733ada30da2ba92a3ad1 (patch)
tree96e70e508afb0631a2f107f6e7a21a07eddc53e6 /.editorconfig
parent69ac07863205ec281bcd2f2e6571202da0c315f7 (diff)
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>
Diffstat (limited to '.editorconfig')
0 files changed, 0 insertions, 0 deletions