Rock Pi S - I2S0 - anyone getting clean 96/192kHz?

#1

Hi, I cannot get clean 192kHz I2S0 loopback (SDOx -> SDIy) on Pi S, despite the RK3308 I2S0 192kHz specs.

I am testing maximum working I2S samplerates. Simple kernel modification allows samplerates up to 768kHz (just increasing limits in the alsa drivers).

I have already tested other RKs:
RK3566 (Radxa CM3) - clean 192kHz, clean 384kHz, few issues at 768kHz
RK3588S (Radxa CM5) - clean 192kHz, few issues at 384kHz, many issues at 768kHz

By “issues” I mean dropped samples and added zero samples in the captured stream, clearly visible on the sine signal in audacity. These are not alsa xruns (none reported), it’s always just a few samples (1 to 10). My hypothesis is the I2S FIFO - AHB - DMACx - RAM chain does not keep up transferring samples reliably: dropped samples in the captured stream are I2S FIFO overflows on the RX side, zero samples are I2S FIFO underflows on the TX side (I2S sending zeros instead).

The RK3566 and RK3588S “issues” are OK, the interfaces are specced only up to 192kHz where their performance is flawless. But I get consistent “issues” on RK3308 8ch I2S interface at 192kHz, even if transferring only 2 channels. 96kHz performance is OK.

I tried changing DMA burst size to the maximum 16 and to small 4 in https://elixir.bootlin.com/linux/latest/source/sound/soc/rockchip/rockchip_i2s_tdm.c#L1634 + https://elixir.bootlin.com/linux/latest/source/sound/soc/rockchip/rockchip_i2s_tdm.c#L1640 , with more “issues” than the original 8.

On RK3308 the HCLK (the AHB clock, IIUC) runs at 98MHz which perhaps may be too low for 192kHz samplerate. AHB clock on RK3566 runs at 150MHz default (I actually increased that to 200MHz by reverting the patch https://github.com/radxa/u-boot/commit/65bd598f415b92d2165e52a757e70f85352eba25 ). I think AHB clock of RK3588 is at least 200MHz, IIRC.

Cpufreq governor is set to “performance” on all cores, no switching cpu frequencies. Only ethernet is being used, no USB gadget etc.

Please has anyone had consistent success with 192kHz I2S0 on the Pi S?

Please see the attached spectrogram - 8ch 192kHz 1kHz signal - first 4 secs issues, then suddenly perfectly clean. Somehow the transport “recovered”. Next time issues again. The captured wav was stored to tmpfs, no slow SD card involved. Is there any way to troubleshoot these low-level issues?

spectrogram
spectrogram.png938×605 50.4 KB

RockPi S + CS42448 I2S/I2C DAC setup
Rock Pi S + radxa kernel linux-6.1-stan-rkr1 - inactive USB host?
#2

This is detail from audacity - a few extra zero samples added, no real samples dropped.

audacity
audacity.png188×1235 2.54 KB

#3

This is spectrogram from 96kHz which is not 100% reliably clean either. IMO the added zero samples only in the first 4 channels really suggest that the bottleneck is somewhere in the delivery between RAM/DMAC1 and the I2S FIFOs. The spectrogram suggests that the 4 FIFOs are served on round-robin basis, and in this particular case the first two FIFOs underflew while the remaining two FIFOs were served on time. Note how samples in the corrupted tracks are shifted to the right, by the one added zero sample.

Please is there any way to improve performance of the bus, at least to make the 96kHz samplerate practically usable? Any missing/corrupted sample is a show stopper for practical usage as it produces an audible click.

spectrogram
spectrogram.png941×605 7.71 KB

samples
samples.png183×1064 2.79 KB

#4

Increased clock hclk_audio (clocking the I2S hclk) from 100MHz to 400MHz (max working)

      clk_audio_src               2        2        0  1179647999          0     0  50000         Y
         pclk_audio               1        1        0    98304000          0     0  50000         Y
            pclk_acodec           0        0        0    98304000          0     0  50000         N
            pclk_audio_niu        0        0        0    98304000          0     0  50000         Y
         hclk_audio               2        2        0   393216000          0     0  50000         Y
            hclk_vad              0        0        0   393216000          0     0  50000         N
            hclk_i2s1_2ch         0        0        0   393216000          0     0  50000         N
            hclk_i2s0_2ch         0        0        0   393216000          0     0  50000         N
            hclk_i2s3_8ch         0        0        0   393216000          0     0  50000         N
            hclk_i2s2_8ch         0        0        0   393216000          0     0  50000         N
            hclk_i2s1_8ch         0        0        0   393216000          0     0  50000         N
            hclk_i2s0_8ch         2        2        0   393216000          0     0  50000         Y
            hclk_spdifrx          0        0        0   393216000          0     0  50000         N
            hclk_spdiftx          0        0        0   393216000          0     0  50000         N
            hclk_pdm              0        0        0   393216000          0     0  50000         N
            hclk_audio_niu        0        0        0   393216000          0     0  50000         Y
      clk_wifi_vpll0              0        0        0  1179647999          0     0  50000

and aclk_bus (clocking the DMACs) from 200MHz to 430MHz (max working)

      clk_bus_src                 3        3        0  1300000000          0     0  50000         Y
         aclk_bus                 2        3        0   433333334          0     0  50000         Y
            aclk_dmac1            1        1        0   433333334          0     0  50000         Y
            aclk_dmac0            0        1        0   433333334          0     0  50000         Y
            aclk_gic              0        0        0   433333334          0     0  50000         Y
            aclk_vop              0        0        0   433333334          0     0  50000         N
            aclk_crypto           0        0        0   433333334          0     0  50000         N
            aclk_intmem           0        0        0   433333334          0     0  50000         Y
            aclk_bus_niu          0        0        0   433333334          0     0  50000         Y
         hclk_bus                 1        1        0   100000000          0     0  50000         Y

No notable improvement in 96kHz. Default clocks (11 minutes recording):

spectrogram-standard-ok
spectrogram-standard-ok.png944×605 12.3 KB

The substantially faster clocks:

spectrogram
spectrogram.png944×605 9.86 KB

I really have no idea what to tweak more to improve the throughput and reliability. I tend to worry the SoC performance is not up to the task (which is sad as even smaller STM32s run I2S at 768kHz).

#5

Really nobody has properly tested this board at > 48kHz?

RK3308B or RK3308B-S?