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

[phofman]

@phofman, I read about the Rockchip64, but could not clearly see how it is a multi i2s device on its output, or how it could be configured via pheriphals to become that.

Rockchip64 SoCs implement multiple I2S interfaces, some 8ch (TDM and/or multiple IO lines). Check e.g. https://wiki.radxa.com/RockpiS/hardware/gpio#Hardware_V13

But I have read a little about IanCanadas products over at https://github.com/iancanada/DocumentDownload. As it seems to me, those are probably good examples on products that will gladly take on the jitterfree quality audio transport towards the DACs in the end of the chain, as delivered from a Soc multichannel i2s (or the MiniDSP USB Streamer's) output. Interesting ambition, at least.

Using the I2S output in slave mode requires no jitter cleaning as the clocks are by the DAC. Of course running RPi I2S in master mode and using RPi-generated jittery clock (like most RPi audio hats do) is extremely suboptimal https://www.diyaudio.com/community/threads/avoiding-rpi-master-i2s-fractional-jitter.376583/

 

[chj]

RockPIS looks kind of promising, and what a pricepoint, albeit there is little focus on i2s out, even from the vendor. I ordered it, thanks for the tip. I did find this thread were "eragefe" seems to be an early adopter and make TDM8 (I anticipate that is meant with i2s_8ch output from Rockpis) to work on Armbian, though limited to SR48 with 8 channels. https://forum.radxa.com/t/i2s-out-overlay-to-enable-i2s0/4222/40. And how well did it work, not easy to conclude.

I dont know if SR48 for 8x is a limitation in TDM or was by his coincidental choice, but the MiniDSP USB streamer can only output 4channels when running SR96, which is a preferrable minimum max-SR for high-end hifi.

If possible, I will use e.g. RockPIS with TDM8 with Linux running. 2ch input, minimum 4ch output. I really hope this will be doable, but could be a wet dream only. Linux will then be mature and handle whatever SR it gets on the receiving side. The SoC will then run a proprietary DSP (See soundpimp.com for software version, btw also available for Linux), which is a forerunner to a "next version" that I now have running in software on Windows/Mac as connected to DACs via RME Digiface USB. That prototype works well. Fantastic sound quality with ESS DACs (which is what I have). The ambition is to move the software from a laptop prototype and over to a soC, as a fundamental part of the complete DAC system. The Rock X with Win10 compliance is then another alternative.

However, it looks like I need some "hat" that presents 8 (or 4 in my case) physical i2s pins for the TDM8. So as to connect with the DACs (2 of them, both stereo). Are you aware of such a "hat" product?

The backup solution is MiniDSP USB streamer connected to reclockers&DACs. I can then use (hopefully) whatever soC as USB Host and get it going, and why not that sleeky Rock PI S. The DSP software runs fine on a x86 laptop slowed down to 750Mhz, so it should be suffiently powerful.

 

[Red@]

Hello phofman,
Any news on your commits acceptance in kernel 5.17?
Also a small question, in case the kernel is good for dynamic resampling would it be usable with camilla dsp through the same process describe in the OP ?

 

[phofman]

All my major commits plus a number of important commits by other devs are accepted for next kernel release - 5.18. I believe that should be the kernel which will support all major features of the gadget.

CamillaDSP will support the gadget behavior at version 1.1 https://www.diyaudio.com/community/threads/linux-usb-audio-gadget-rpi4-otg.342070/post-6935965

 

[Red@]

All my major commits plus a number of important commits by other devs are accepted for next kernel release - 5.18. I believe that should be the kernel which will support all major features of the gadget.

CamillaDSP will support the gadget behavior at version 1.1 https://www.diyaudio.com/community/threads/linux-usb-audio-gadget-rpi4-otg.342070/post-6935965

Great news man. Please keep us posted.
And thank you for sharing the link.

 

[Red@]

All my major commits plus a number of important commits by other devs are accepted for next kernel release - 5.18. I believe that should be the kernel which will support all major features of the gadget.

CamillaDSP will support the gadget behavior at version 1.1 https://www.diyaudio.com/community/threads/linux-usb-audio-gadget-rpi4-otg.342070/post-6935965

Hello, any news on this project ?
thanks

 

[phofman]

RPi has published their patched 5.18 https://github.com/raspberrypi/linux/tree/rpi-5.18.y incl. gadget compilation bugfix https://github.com/raspberrypi/linux/issues/4992#issuecomment-1102513613

The camilladsp branch next11 has all the required patches too https://github.com/HEnquist/camilladsp/commits/next11

Just compile and test, any feedback is appreciated. Thanks.

 

[audiofun]

RPi has published their patched 5.18 https://github.com/raspberrypi/linux/tree/rpi-5.18.y incl. gadget compilation bugfix https://github.com/raspberrypi/linux/issues/4992#issuecomment-1102513613

The camilladsp branch next11 has all the required patches too https://github.com/HEnquist/camilladsp/commits/next11

Just compile and test, any feedback is appreciated. Thanks.

Can you post a short guide (or commit it to the camilladsp doc) to make it easier for people to set it up?

 

[Red@]

@phofman indeed it would be very much appreciated to have a little guide as it is not perfectly my area of expertise.
also does it support dynamic sampling by default ?
thank you very much for your valuable work

 

[DeLub]

RPi has published their patched 5.18 https://github.com/raspberrypi/linux/tree/rpi-5.18.y incl. gadget compilation bugfix https://github.com/raspberrypi/linux/issues/4992#issuecomment-1102513613

The camilladsp branch next11 has all the required patches too https://github.com/HEnquist/camilladsp/commits/next11

Just compile and test, any feedback is appreciated. Thanks.

I've compiled the kernel, compiled camilladsp and everything was stil fine. Then I changed c_srate in /etc/modprobe.d/usb_g_audio.conf to the list that matches my usb dac. From my mac I am now able to select all the available sample rates, so far so good. But I'd probably need to change something to the camilladsp config file as well, as it only works correctly when I set the sample rate to 48kHz. Can you help out please?

I'll update the guide in the original post once I have things figured out.

 

[phofman]

CamillaDSP does not support multiple samplerates and Henrik has repeatedly stated that he does not intend to implement this feature (yet). The binary has command-line parameters for a config file and for a different samplerate than in the config. AFAIK filters need different coeffs for different samplerates, i.e. different config files for different samplerates are the only option.

Therefore CDSP needs to be restarted to run at a different samplerate. Samplerate change is communicated via gaudio alsa ctl "Playback Rate" which notifies subscribed clients about a change. I made a simple gaudio controller for that https://github.com/pavhofman/gaudio_ctl . The default params run alsaloop for the capture-playback bridge, but you can define a param string (-x) to start CDSP with appropriate config files (i.e. -x 'PATH_TO_CDSP/camilladsp config-{R}.yml' with config-48000.yml, config-96000.yml etc.)

 

[audiofun]

CamillaDSP does not support multiple samplerates and Henrik has repeatedly stated that he does not intend to implement this feature (yet). The binary has command-line parameters for a config file and for a different samplerate than in the config. AFAIK filters need different coeffs for different samplerates, i.e. different config files for different samplerates are the only option.

Therefore CDSP needs to be restarted to run at a different samplerate. Samplerate change is communicated via gaudio alsa ctl "Playback Rate" which notifies subscribed clients about a change. I made a simple gaudio controller for that https://github.com/pavhofman/gaudio_ctl . The default params run alsaloop for the capture-playback bridge, but you can define a param string (-x) to start CDSP with appropriate config files (i.e. -x 'PATH_TO_CDSP/camilladsp config-{R}.yml' with config-48000.yml, config-96000.yml etc.)

sounds just like https://github.com/scripple/alsa_cdsp/

Tools like this still have very high bar for users that frightens them away. Looking forward to a clearer guide.

 

[phofman]

Tools like this still have very high bar for users that frightens them away. Looking forward to a clearer guide.

Well, honestly, my view is simple - either learn (and help, eventually), or pay/motivate someone who would iron out all the details and integrate it into some complex ready-to-use solution. That's where e.g. Roon, Volumio etc. are heading. Moode is an exception for now but I think they will follow the same path eventually, which I would find perfectly fine...

 

[DeLub]

CamillaDSP does not support multiple samplerates and Henrik has repeatedly stated that he does not intend to implement this feature (yet). The binary has command-line parameters for a config file and for a different samplerate than in the config. AFAIK filters need different coeffs for different samplerates, i.e. different config files for different samplerates are the only option.

Therefore CDSP needs to be restarted to run at a different samplerate. Samplerate change is communicated via gaudio alsa ctl "Playback Rate" which notifies subscribed clients about a change. I made a simple gaudio controller for that https://github.com/pavhofman/gaudio_ctl . The default params run alsaloop for the capture-playback bridge, but you can define a param string (-x) to start CDSP with appropriate config files (i.e. -x 'PATH_TO_CDSP/camilladsp config-{R}.yml' with config-48000.yml, config-96000.yml etc.)

Thanks! This seems to work, although I had to use the -y parameter. Since I do not care for playback, only capturing, is there a way to disable this? I now use -x "sleep infinity"

 

[phofman]

DeLub: Excellent work, very good.

Yes, -y is the correct param, sorry for the confusion. To avoid playback (gadget -> host), IIRC (some time has passed by ) by looking at the source code https://github.com/pavhofman/gaudio_ctl/blob/master/src/bin.rs#L121 you just need to disable the playback side in the gadget module param, by setting p_chmask=0 (i.e. the USB host cannot capture). That will eliminate the 'Playback Rate' ctl creation which triggers the playback binary execution in gaudio_ctl.

 

[Vincent Kars]

I want to eq the sound and this is not possible on iOS

I see a couple of programs doing so listed here

EQ Software for Windows, Linux, macOS, iOS/iPadOS and Android.

Any suggestions are welcome. Post suggestions here. I will gather the details and add them. Thanks. :D This will be organized as results come in. @sweetchaos made a guide for PEQ filter data input and operation. For crossover software go here. Windows: AutoEQ four easy steps to make your...

www.audiosciencereview.com

What is wrong with them?

 

[DeLub]

What is wrong with them?

They only work within their respective apps and not systemwide. For example, there is no way to eq music playing from the apple music app.

 

[Vincent Kars]

I see, thanks

 

[audiofun]

Well, honestly, my view is simple - either learn (and help, eventually), or pay/motivate someone who would iron out all the details and integrate it into some complex ready-to-use solution. That's where e.g. Roon, Volumio etc. are heading. Moode is an exception for now but I think they will follow the same path eventually, which I would find perfectly fine...

No. I didn't mean cdsp/usb gadget are hard to learn. What I mean is currently there's almost zero documentation regarding how to set up gadget with cdsp together. CamillaDSP provides excellent documentation. But the gadget is not. At least let us know how to make them work together.

in my understanding, the step includs

1. install camilladsp. this is easy and CamillaDSP doc already covers that
2. install linux kernel 5.18. Easy. most distributions have the doc.
3. set up the gadget: My understanding is to 1) add dwc2 and g_audio to /etc/modules 2) edit '/etc/modprobe.d/usb_g_audio.conf'. where's the doc for this?
4. setup a config file: What's the recommended setup for the device part given the usb_g_audio.conf above?

Extra question: Where can I find the doc to sync the gadget clock to an external DAC?

It's OK for tools like yours to have a steep learning curve. But it doesn't mean open source / free of charge code does not deserve good documentation. Maybe the documentation is already there for the gadget but I cannot simply find it. In this case I apologize for the above comment.

 

[DeLub]

CamillaDSP does not support multiple samplerates and Henrik has repeatedly stated that he does not intend to implement this feature (yet).

That's unfortunate, but so far using your gaudio_ctl works fine.

Just out of curiosity, because I couldn't figure it out: what do your patches in CDSP branch next11 accomplish? (I actually hoped those were supporting the dynamic rate switching)

I'll update my OP in the next couple of days.