[pulseaudio-discuss] Latency/lag with tcp tunnel

[Matt Garman]

Reviving this two-month-old thread for a little FYI follow-up.  Quick
recap: I was experiencing noticeable lag/latency between my pulse
client PC and my pulse server Raspberry Pi.  Turns out most of it was
due to the Allo Kali device I was using between the RPI and audio
device.  However...

On Wed, Jan 27, 2021 at 2:23 AM Sean Greenslade <sean at seangreenslade.com> wrote:
> So this is where the limitations of module-tunnel come in. The original
> tunnel has the latency modification code commented out, so you're stuck
> at the default sink latency setting of 250 ms.
>
> One thing you can try is using module-tunnel-sink-new instead of
> module-tunnel-sink, as it seems to have dynamic latency calculations
> in its code (though I'm not familiar enough with the PA internals to
> know how that code actually works).

...while removing the Allo Kali device got me well into "good enough"
territory, I remained curious about tunnel-sink-new.  Finally got
around to giving it a try.  For review, this is what I typically saw
for latency on the old/original tunnel sink module:

Latency: 137764 usec, configured 250000 usec

The new module clearly has some dynamic calculations going on.  I
hacked up a little script to periodically run "pactl list sinks" and
grep the latency info for the module-tunnel-sink-new.  What's
interesting to me is that the "configured" latency seems to fall into
one of three buckets: 11, 75, or 200 ms.  Here are a few samples from
my "latency logger":

Latency: 184712 usec, configured 200000 usec
Latency: 203054 usec, configured 200000 usec
Latency: 64141 usec, configured 75000 usec
Latency: 84139 usec, configured 75000 usec
Latency: 19927 usec, configured 11610 usec
Latency: 25305 usec, configured 11610 usec

There are actually a lot of "Latency: 0 usec, configured 0 usec"
records, which correspond to when there is no playback (i.e. idle
sink).  What I find interesting is that it seems like the configured
latency value corresponds to the application that causes the sink to
transition from idle to active.  In particular, playing Minecraft
almost always results in the 11.6ms configured latency.  Spotify
always results in the 200ms configured latency.  And it seems
"everything else" triggers the 75ms latency.

What's also interesting is that when the new tunnel module falls into
the 200ms bucket, the reported latency of 180--200ms is higher than
when using the old module, which was generally around 140ms, despite
the configured 250ms latency.

At any rate, I'm happy with the state of things currently, just
thought I'd post some data that others might find interesting.