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@xxxxxxxxxxxxxxxxxx> 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. _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
