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