[pulseaudio-discuss] Latency/lag with tcp tunnel
sean at seangreenslade.com
Tue Jan 26 04:58:18 UTC 2021
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
> 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
> 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
> 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
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
Owner Module: 9
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\""
Volume: front-left: 60293 / 92% / -2.17 dB, front-right: 60293 / 92% / -2.17 dB
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).
More information about the pulseaudio-discuss