On Sonntag, 9. Januar 2022 18:06:44 CET Volker Rümelin wrote: > > On Donnerstag, 6. Januar 2022 10:21:47 CET Volker Rümelin wrote: > >> This patch series reduces the playback latency for audio backends, > >> in some cases significantly. For PulseAudio, the audio buffer is > >> also moved from the QEMU side to the PulseAudio server side. This > >> improves the drop-out safety for PulseAudio. > >> > >> I actually measured the latency reduction with the PulseAudio > >> backend. For the test I used my Linux host configured to play > >> audio with PulseAudio. The guest was a Linux guest, also > >> configured to use PulseAudio. > > > > I haven't reviewed all the patches yet, but from what I read so far, does > > that mean the additional 3rd buffer is solely for PulseAudio, so for JACK > > and other backends these changes would overall be a degradation, wouldn't > > they? > No, nothing changes for JACK and it's an improvement for all the other > backends where I added a buffer_get_free function. The important changes > are in [PATCH 10/15] audio: restore mixing-engine playback buffer size. > That patch tries to keep the mixing-engine buffer empty at the end of > audio_run_out(). > > I couldn't reduce the playback latency for JACK, because the JACK audio > buffers are already very small and any further reduction introduces > playback glitches on my system.
And that's actually my concern. A split 2 buffers -> 3 buffers while (approximately) retaining overall latency increases the chance of dropouts. > For PulseAudio there is no additional buffer. I only increased the size > of the server side buffer from 15ms to 46,4ms and added a > buffer_get_free function. Before this patch series a few ten ms after > playback started the mixing-engine buffer was full which added 2 * > 46,4ms to the playback latency. With these patches the mixing-engine > buffer is empty. This looks like the buffer in use was moved from the > mixing-engine to the PulseAudio server side.
