Using a Raspberry Pi as equaliser in between an USB source (iPad) and USB DAC

[phofman]

@godmax: Making any non-RPi ARM board work properly with any reasonably new kernel is ALWAYS a major fight. Most of SoC manufacturers care about android kernel only, android is their market. Very few customers actually request/run non-android linux on non-RPi SoCs. If you are not deeper into kernel development, stay with RPi. I really mean it, honestly.

Upstreaming android patches to mainline kernel is a very tedious work, prone to MANY errors. Some SoC vendors contract specialized linux engineering companies for upstreaming their countless android-kernel patches and hacks - emails of these specialty companies appear daily on mailing lists related to ARM technologies/subsystems. But their patches are buggy too and often need several iterations to fix. I don't blame them - it's how development works.

Armbian is a huge effort, but again no way it could be bug-free as it "only" collects patches. Just like Radxa BSP https://github.com/radxa-repo/bsp/tree/main/linux or Radxa patched android kernel https://github.com/radxa/kernel/tree/linux-6.1-stan-rkr1/arch/arm64/boot/dts/rockchip .

As of your crashing DWC2 issue - this helped me on recent kernels https://github.com/torvalds/linux/commit/ca2dc35e555e7043de585f4e46123d8fbd2b5a21

Just a note - here is not a good place to try find help with the Pi S. Sometimes Radxa forums help - I tried a few times https://forum.radxa.com/u/pavel_hofman/activity . But as I said - it's a low-level kernel work to (try to) make things tick correctly, nothing will work out of the box.

 

[godmax]

@godmax: Making any non-RPi ARM board work properly with any reasonably new kernel is ALWAYS a major fight. Most of SoC manufacturers care about android kernel only, android is their market. Very few customers actually request/run non-android linux on non-RPi SoCs. If you are not deeper into kernel development, stay with RPi. I really mean it, honestly.

Upstreaming android patches to mainline kernel is a very tedious work, prone to MANY errors. Some SoC vendors contract specialized linux engineering companies for upstreaming their countless android-kernel patches and hacks - emails of these specialty companies appear daily on mailing lists related to ARM technologies/subsystems. But their patches are buggy too and often need several iterations to fix. I don't blame them - it's how development works.

Armbian is a huge effort, but again no way it could be bug-free as it "only" collects patches. Just like Radxa BSP https://github.com/radxa-repo/bsp/tree/main/linux or Radxa patched android kernel https://github.com/radxa/kernel/tree/linux-6.1-stan-rkr1/arch/arm64/boot/dts/rockchip .

As of your crashing DWC2 issue - this helped me on recent kernels https://github.com/torvalds/linux/commit/ca2dc35e555e7043de585f4e46123d8fbd2b5a21

Just a note - here is not a good place to try find help with the Pi S. Sometimes Radxa forums help - I tried a few times https://forum.radxa.com/u/pavel_hofman/activity . But as I said - it's a low-level kernel work to (try to) make things tick correctly, nothing will work out of the box.

Thank you for your comprehensive reply! Maybe I should have gone for an RPi 5 (again, you need a USB-C splitter for power and an external power supply), but I really liked the form factor and feature set of the Rock Pi S.

But I don't think Radxa has made it easy for their customers either, as some of the documentation is incomplete, outdated or incorrect. The hardware revision has been silently reverted from the "new" RK3308B-S version to the "old" RK3308B version, while it is still listed as V1.3 revision for their latest production models - very confusing.

And also the supplied images are more than inconsisent or outdated. Their "newest" b40 has very different kernel config as their old 4.4 images. I refrain from configuring and building kernels myself, even if the latest changes might improve overall stability, as this opens the door to another potentially time-consuming bug field.
I saw your activity on the Radxa forum already, you are one of the few there that they actually anwser to and also make changes based on your feedback

Meanwhile I once more started over and used this time Armbian Jammy image with the "new" propper USB UAC2 ConfigFS settings and it worked out of the box (OK only with 16bit format, since 24bit does not even show up and with 32bit it crashed again when you playback from PC). Now I will start with CamillaDSP configuration and sample rate switching lets see what new errors arise

 

[phofman]

but I really liked the form factor and feature set of the Rock Pi S.

So do I. RK3308 is designed specifically for audio and its feature set is quite unique. But Pi S does not expose all the handy capabilities of the SoC. The low consumption which allows to power the SoC from standard USB port even when running at full 4 cores @1.3GHz is very handy too.

I refrain from configuring and building kernels myself

I am afraid there is no way to get around that on non-RPi ARM.

But I don't think Radxa has made it easy for their customers either,

No ARM SBC vendors apart of RPi offer kernel close to mainline which fully support their products. Even RPi has yet to support a number of useful RPi5/RP1 features.

Radxa does decent HW for decent prices, reasonably long product lifetime, has reasonable sales support over email, speaking good english. And that's not standard in this market. They do not have enough workforce (no even close) to support their HW on mainline. In fact that is job of Rockchip which IMO hired Collabora for some mainlining https://gitlab.collabora.com/hardwa...-rockchip-3588/-/blob/main/mainline-status.md .

Radxa at least try to help with runnning mainline, they maintain their BSP build system (which needs some hacking to be actually useful for making kernel modifications).

Meanwhile I once more started over and used this time Armbian Jammy image with the "new" propper USB UAC2 ConfigFS settings and it worked out of the box (OK only with 16bit format, since 24bit does not even show up and with 32bit it crashed again when you playback from PC). Now I will start with CamillaDSP configuration and sample rate switching lets see what new errors arise

I am afraid they will arise. The gadget code still receives important patches which need to be applied, using old android kernel is not possible. On the other hand mainline kernel has some I2S-DMA issues on Rockchip, IME. Radxa/Rockchip may or may not fix them https://forum.radxa.com/t/rock-pi-s-radxa-kernel-linux-6-1-stan-rkr1-inactive-usb-host/20552/5

The RPi5 path is definitely MUCH easier, if only 8ch in/out I2S is required.

 

[IAtaman]

I have tested Orange Pi Zero2 just now, and that also works fine. It works the same way it works with Rock Pi S - power and data in through USB C, data out to DAC from USB A. No other wired connections are required.

One major advantage over RockPiS is that it works with much recent Kernel (6.6.16) and UAC2.

It works both with older CamillaDSP 1.x and new 2.x versions.

While testing, I realized CamillaNode does not work with CamillaDSP 2.x. Which is as well - I wanted to update CamillaNode and add separate controls for L and R anyway.

 

[IAtaman]

I have tested Orange Pi Zero2 just now, and that also works fine. It works the same way it works with Rock Pi S - power and data in through USB C, data out to DAC from USB A. No other wired connections are required.

One major advantage over RockPiS is that it works with much recent Kernel (6.6.16) and UAC2.

It works both with older CamillaDSP 1.x and new 2.x versions.

While testing, I realized CamillaNode does not work with CamillaDSP 2.x. Which is as well - I wanted to update CamillaNode and add separate controls for L and R anyway.

Using OrangePi Zero2 as an equalizer between USB source and USB DAC

For roughly $30, half an hour of your time and some opensource freeware, you can get a USB in USB out digital equalizer that you can use with any digital source and DAC. There are quite a few options out there for hardware and software choices, but the one I personally find most convenient and...

www.audiosciencereview.com