Re: [PATCH 00/15] reduce audio playback latency

[Volker Rümelin]

Am 10.01.22 um 14:11 schrieb Christian Schoenebeck:
> 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.

No, the 3 * 512 frames JACK buffer improves dropout safety compared to a 
2 * 512 frames buffer. Before my patches I could sometimes hear glitches 
when I switched from and to the QEMU GTK window. With the change to a 3 
* 512 frames JACK buffer, audio playback is glitch free and it comes 
without additional playback latency.

> > 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.