[pulseaudio-discuss] Latency/lag with tcp tunnel

[Sean Greenslade]

On Mon, Jan 25, 2021 at 07:33:56PM -0600, Matt Garman wrote:
> I am using a Raspberry Pi as a "sound server".  Essentially, the RPI
> is connected to the actual audio hardware.  The RPI advertises itself
> via module-native-protocol-tcp and module-zeroconf-publish.  My
> desktop/workstation in turn uses the RPI for playback via
> module-tunnel.
> 
> Everything seems to work as expected, except there is a noticeable lag
> between doing something on the PC, and having the audio "catch up" on
> the RPI.  For example, watching YouTube - the audio and video are out
> of sync to the point of being unwatchable.  Or using a simple audio
> player on the PC, hitting "play" or "stop", there is a noticeable
> delay from when the button is pressed to when the action actually
> takes effect.
> 
> I can't think of a good way to measure the lag, but I'm guessing it's
> around half to three fourths of a second.
> 
> To be clear, there are no stutters or skips or other audio artifacts.
> Playback is smooth and sounds as good as I expect - but the lag is a
> problem.
> 
> What's interesting is, this is actually the second RPI sound server
> I've built.  The first one had this lag, but to a much smaller degree,
> as in, barely noticeable.  The differences between the systems are:
> the first (barely noticeably lag) is an RPI 4, connected to a Topping
> D70 DAC.  The new system (with the obvious latency issue) is an RPI 3,
> connected to an MA12070P-based amplifier.  IOW, the RPI hardware and
> audio hardware are different.  But the network is the same, and the
> devices are all in the same physical location (i.e. same cable
> length).
> 
> The RPI 3 does have only 100mbps network, and the RPI 4 has gigabit.
> The rest of the network chain is all gigabit.  These are all hardwired
> networks (i.e. no wireless).  I feel like 100mbps is more than
> sufficient for CD-quality audio.  The RPI isn't running any other
> services or doing any other work.
> 
> Any thoughts on how I might track this down?  Or what config options I
> can play with to see if it improves the situation?  Also, as the RPI
> is headless, I can't think of a good way to determine if the latency
> is on the RPI itself, or comes from the network between the PC and
> RPI.

As a data point, I routinely use networked TCP streams with pulse, and
on wired ethernet links I tend to see only ~50 ms of delay.

One avenue to investigate is to see what pulseaudio thinks the latency
is. If you run the command "pactl list sink_inputs" on the device with
the sound card, you'll get something like this:

[sean at bailey ~]$ pactl list sink-inputs
Sink Input #2
	Driver: protocol-native.c
	Owner Module: 9
	Client: 17
	Sink: 3
	Sample Specification: float32le 2ch 48000Hz
	Channel Map: front-left,front-right
	Format: pcm, format.sample_format = "\"float32le\""  format.rate = "48000"  format.channels = "2"  format.channel_map = "\"front-left,front-right\""
	Corked: no
	Mute: no
	Volume: front-left: 60293 /  92% / -2.17 dB,   front-right: 60293 /  92% / -2.17 dB
	        balance 0.00
	Buffer Latency: 226791 usec
	Sink Latency: 16780 usec
	Resample method: speex-float-1

Note the reported "Sink Latency" of ~16 ms (in my setup, I saw it vary
from 4 ms to 25 ms). What does your setup report? And what is the
reported latency of your audio device itself (pactl list sinks).

--Sean