[pulseaudio-discuss] Latency/lag with tcp tunnel

[Sean Greenslade]

On Fri, Jan 29, 2021 at 08:16:15AM -0600, Matt Garman wrote:
> Hi Matt and Sean, thank you so much for your help!  I was planning to
> try removing the Kali, but Sean's email pushed me to try it sooner
> than later.  I did just that last night, and now the lag is all but
> gone.  Using paplay directly on the RPI results in *immediate*
> playback, as soon as I hit enter (before there was a very noticeable
> delay).  VIdeos are once again watchable (using my PC for the monitor
> and as a pulseaudio client to the RPI server).  There's still a very
> tiny latency that is perceptible in some cases - but this is the same
> as what I experienced with the RPI 4 and different DAC/amp combo.
> This I can live with, though I might try to further tweak a bit to see
> if it can be completely eliminated.

Glad you were able to solve your issue! For small video sync issues, I
would look to your video player's settings. For example, smplayer has an
"autosync" feature that inspects the reported delay from the pulse chain
and tweaks the A/V sync to compensate. There's also a coarse sync adjust
with the +/- buttons (in 100 ms increments). I'm sure other video
players have similar features.

> A few somewhat off-topic comments below...
> <SNIP>
> I think it is true that, for 44.1khz sample rates (and its multiples),
> indeed the RPI cannot exactly generate that clock, as it's master
> clock is not an integer multiple of that (looks like 19.2 MHz for RPI3
> and earlier, 54.0 MHz for RPI4).

This digs into some pretty deep details of microprocessor clocking, but
it does not need to be an exact integer multiple.

The Pi's clocking system uses something called a PLL, or Phase-Locked
Loop, to generate higher-speed clocks than the input reference clock.
Think of it as an integer multiplier; you give it 19.2 MHz, then it can
give you 2*19.2, or 3*19.2, or 43*19.2 (up to some maximum limit that
the hardware is capable of). Once you have your faster clock, it is
passed to an integer divider to get to the final clock speed you want.
This divider can be set to any integer value, thus you have a
"fractional" PLL. In this case, you want 2.8224 MHz from 19.2 MHz. Using
some least common multiple math, we get a multiplier of 147 and a
divider of 1000. 19.2 MHz * 147 = 2.8224 GHz / 1000 = 2.8224 MHz exactly.

Now, 2.8 GHz is pretty fast, so it may be the case that the Pi's PLLs
can't get to that speed. Without the full datasheet for the chip (which
Broadcom has refused to publically publish), I can't say for sure if the PLL
would tolerate a clock that fast. I did find an article [0] on
raspberrypi.org that mentions a PLL max of 3.2 GHz, so it may be OK.

Now, there may be any number of other reasons why the Pi specifically
can't do this (the most likely being that the PLLs and clock domains are
shared among a number of peripherals, so their frequencies may be fixed
or restricted), but I wanted to point out why the non-integer division
factor is not fundamentally a problem. 

> However, whether or not that makes a difference is dependent on the
> downstream component's ability to adapt.

And even if the clock is using an imperfect multiple, that generally
won't cause actual problems. If your 44.1 kHz audio is being fed out to
the DAC at 44.05 kHz, your audio will simply be reproduced a tiny bit
slower and lower-pitched than the original. You probably wouldn't even
notice it. Hell, TV broadcasts of 24 fps movies in PAL regions will
often times just play it back at 25 fps (though I would imagine anyone
with perfect pitch would be rather annoyed by this).

--Sean

[0]: https://hackspace.raspberrypi.org/articles/ultimate-overclocking