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