[pulseaudio-discuss] low-latency

[pl bossart]

Hi,
I am still trying to configure PulseAudio for a low-latency app, and I
could not figure why the latency reported is much higher than what I
specified. For example, with tsched=0 and four fragments of 5ms, the
latency wouldn't go below 40ms, no matter how I specified the latency
parameter.

Turns out that in protocol-native.c, we have this piece of code:
   /* FIXME: This is actually larger than necessary, since not all of
    * the sink latency is actually rewritable. */
   if (tlength_usec < s->configured_sink_latency + 2*minreq_usec)
       tlength_usec = s->configured_sink_latency + 2*minreq_usec;

Essentially this test limits our ability to reduce the latency below
twice the size of the hardware buffer. I believe it is overkill for
low-latency apps where you don't really want to rewrite in the
hardware buffer in the first place. If there's any mixing to be done,
it could start when the next write happens, no need to rewind. The
only thing you would want is to have one fragment stored in the server
buffer, and this might even be overkill.
Interestingly I commented out this piece of code, yet I still show a
latency in the 40ms, looks like sink_input_update_max_request_cb()
changes tlength and hence the latency as well. Not sure why?
Feedback welcome,
- Pierre