[pulseaudio-discuss] Latency/lag with tcp tunnel
matthew.garman at gmail.com
Fri Jan 29 14:16:15 UTC 2021
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.
A few somewhat off-topic comments below...
On Thu, Jan 28, 2021 at 6:39 PM Sean Greenslade <sean at seangreenslade.com> wrote:
> 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.
I do appreciate your analysis, that was an interesting read. In an
earlier email, I said I've been using the Kali for years and never
noticed this latency. But I realized in the past, I only used it for
music playback. IOW, previously, I never used it in a situation where
the lag would actually be an issue. So it's likely been there before,
I just never noticed it.
Your comments about the RPI's I2S jitter are nearly earth-shattering
to me. Years ago, I read that dimdim article you linked. I do not
have the knowledge to identify the test setup/methodology as
questionable, and have since lived with the simple notion that "RPI
I2S == bad", and absolutely requires reclocking. 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). However, whether or not that makes a difference
is dependent on the downstream component's ability to adapt.
I also have an Amanero, which is a USB to I2S device. I might try
playing with it to see if it adds latency, just for kicks.
At least I'm not buying $1000 power cables. ;)
If you guys (or anyone else) are interested in my ma12070p project,
feel free to chat with me off-list. See also this diyAudio thread:
My first post about my project is on page 30, #296.
Thanks again, much appreciated!
More information about the pulseaudio-discuss