Yes, bencharmking with radxa official debian image, which has rockchip 4.4 kernel, does not produce any issue, so the problem lies somewhere in the mainline kernel code and not in the hardware.
Rock Pi S - I2S0 - anyone getting clean 96/192kHz?
Thanks for pointing the radxa branch with an updated pl330.c driver; I tried to compile the 6.12 mainline kernel with pl330.c in the radxa 6.1 kernel repository and, after some trivial adjustments, the issue still persists. I will do some more investigations…
How do you actually do the benchmarking?
IIUC @Nik_Kov tested armbian 6.12 with the pl330.c from that 6.1 repo and it reportedly worked OK, to some extent (which may be the ultimate performance ceiling). At least there is a list of patches applied to mainline by the armbian kernel available.
You can see the commands I used to test and replicate the issue in the Armbian pull request description above.
In particular I first used ogg123 and mbw together, and this caused the issue to appear clearly on mainline kernel with vanilla driver.
After applying a patch that was submitted by Rockchip to kernel mailing lists (but never accepted), these two commands works ok, but if I add another process iperf3 to stress more the memory subsystem, the issue reappears.
After applying applying the radxa pl330.c driver on top of mainline kernel, still produces the issue when all the three processes run together.
What I noticed later, though, is that iperf3 causes the kernel IRQ handler tasklet to fully hog one cpu core. This is unexpected and absolutely not acceptable; it is possible that I hit another issue with the ethernet that is disturbing audio playing, because if I rule out iperf3 and stress test only with ogg123 and mbw, I can’t notice any issues.