[pulseaudio-discuss] Latency/lag with tcp tunnel

[Sean Greenslade]

On Wed, Jan 27, 2021 at 12:32:10PM -0600, Matt Feifarek wrote:
> On Tue, Jan 26, 2021 at 2:09 PM Matt Garman <matthew.garman at gmail.com>
> wrote:
> 
> >
> > The ma12070p is a newish digital input (I2S) class D amplifier
> > (essentially, a "power DAC" or a DAC and amplifier in one chip).
> > Between the RPI and amp is an Allo Kali I2S reclocker.  I don't think
> > the Kali adds any meaningful latency, as I've used it extensively with
> > other I2S DACs, and never before noticed lag.
> 
> 
> I've got a Kali too; it's definitely a buffer; that's its design, I
> believe; essentially a FIFO buffer with good outgoing clocks. You can
> actually see an LED on the board that indicates whether the buffer is full,
> and see that it lags behind audio starting and flushing out. I get that you
> didn't hear a latency before, but I bet that the ma12070 ALSO has a buffer,
> and you're just seeing buffer + buffer + network add up to "perceptible".
> 
> That setup sounds cool, though! I might ask you more about it off list;
> I've been interested in using I2S with the PI, but have always been a bit
> spooked by the details.

I took a brief look into the Kali, and I have to say I'm extremely
skeptical of its benefits. Their marketing copy is full of ridiculous
claims like this:

>>> Furthermore, there are 2 kinds of frequencies for digital files:
>>> 44.1Khz (wave files) and 48khz (streamed music). Some SBCs (like
>>> RPIs) can output only 48Khz, so imagine the degradation of the sound
>>> that was recorded at a different frequency.

44.1 kHz and 48 kHz are just different sample rates, and are not
restricted to specific types of audio. And with a decent resampler,
there is no noticable "degredation of the sound" (though there is
additional latency).

They go on with other silly claims involving a "sea of digital mud"
which border on absurd, but I'll focus on the specific claim that "clock
jitter is bad on the Pi". Since the Allo website does not provide any
actual evidence of this, I had to go searching.

The first blog post I came across alleging clock jitter was this one:

http://www.dimdim.gr/2014/12/the-rasberry-pi-audio-out-through-i2s/

The author of this post uses one of those cheapo knockoff $10 Saleae
clones, sees some noise well within the sampling error, and declares it
"jittery". In my electrical engineering opinion, that test setup is
terrible and those results are meaningless.

Also, the author's claim about the crystal frequency not being an even
multiple of the target frequency is misleading. The Pi, like nearly all
high-speed microprocessors, has a host of fractional PLLs and dividers
for generating its various internal clocks. See:

https://elinux.org/The_Undocumented_Pi#Clocks

So I went on the hunt for a better analysis of the I2S outputs on the
Pi, and lo and behold, someone had a proper scope capture:

http://www.crazy-audio.com/2013/09/raspberry-pi-i2s-output-working/

Amusingly, this was posted over a year _before_ the dimdim.gr post. This
post's author claims to be getting 800 ps of jitter on a 2.822 MHz
clock. That comes out to a 0.2% deviation. I would be amazed if that
added any perceivable distortions to the output.

But wait, there's more. Since you're feeding the signal into an
MA12070P, let's take a look at what that does with its clocks
internally:

>>> The MA12070P incorporates a clock system consisting of an input
>>> clock divider, a PLL, a low-jitter low-TC oscillator (2.8224 MHz),
>>> and control logic. At the CLK input pin the MA12070P requires a
>>> clock signal that is in phase-lock with the incoming digital serial
>>> audio samples. This CLK input signal provides the reference for the
>>> internal PLL through the input clock divider circuit.

It has its own PLL and internal clock, so the incoming I2S signal isn't
even being used to directly clock the DAC output. Yes, having a very
jittery input to a PLL wouldn't be great, but PLLs can tolerate a fair
amount of it. This part didn't spec a jitter tolerance, but an app note
from Maxim claims they have DACs that will tolerate 12 ns(!) of jitter
with clock rates above 40 kHz:

https://www.maximintegrated.com/en/design/technical-documents/app-notes/5/5477.html


Wow, that was kind of a long tangent. Long story short, I would take
that reclocker out of the picture and try feeding your I2S signals
directly to the DAC. Use short connections, shielded if possible, since
I2S is not really meant to be used as a board-to-board protocol.

This may actually help your latency issues, since the Allo claims to
have a 0.7 second (!) buffer.

--Sean