• Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

RPi + CamillaDSP Tutorial

Does the shield running Android 11 actually support multichannel audio output?
your question killed me at first, but after somme researches the answer is YES the shield can do multichannel (Dolby Atmos or Aura 3D are supported) BUT only through HDMI, USB can do audio up to 24-bit/192 kHz but is limited to 2 channels :-(

It looks like it's a limitation shared by all android box devices.
 
Hello.

Could you please tell me if the following setup will work:
Wiim Ultra -> USB -> Raspberry Pi 4 (CamillaDSP + FIR) -> USB -> miniDSP Flex Digital -> optical -> two Topping E70 Velvets.

A power amplifier will be connected to one DAC, and SVS subwoofers to the other.

The miniDSP in this setup acts as a crossover and synchronizes the DAC.

In the future, if I'm satisfied with the results, I'll upgrade to a multichannel DAC, such as a MOTU M4 or Topping DM7 (unfortunately, I can't find one for sale).

Currently, the setup works without a Raspberry Pi (CamillaDSP), but the miniDSP's capabilities aren't sufficient for proper integration and correction of a 2.2-channel system (front speakers and a pair of subwoofers).
I tested the FIR using a computer with JRiver installed as the source, which I connected to the miniDSP, and I was very pleased with the results. But a computer isn't a very convenient source; the Wiim Ultra is much more convenient because you can connect other sources.

And the second question: will the Raspberry Pi4 have enough resources, and how much latency will there be? One of the sources is a TV, and I don't want to experience significant lag.
 
I tried connecting a Raspberry Pi with CamillaDSP installed between the Wiim Ultra and miniDSP. All connections are via USB. The main issue now is the extremely low volume. And as I understand it, the problem isn't with CamillaDSP, but with the USB connection.
If I connect it directly to the miniDSP via USB, the volume remains low.
If I connect it via optical cable to the miniDSP, the volume is as high as it should be.

Is there a way to feed and output a signal to the Raspberry Pi via optical cable and have it processed by CamillaDSP?

My only idea is the HiFiBerry Digi+ I/O. Will it work?
 
Could you please tell me if the following setup will work:
Wiim Ultra -> USB -> Raspberry Pi 4 (CamillaDSP + FIR) -> USB -> miniDSP Flex Digital -> optical -> two Topping E70 Velvets.


One of the sources is a TV, and I don't want to experience significant lag.

Generally if you care about latency, the chain should be as simple as possible, with minimum buffers in between. But I do not know where you want to place the TV into your audio chain.

I would use RPi5 with 8ch I2S and use two SPDIF I2S outputs https://www.aliexpress.com/item/1005008112463155.html . But those boards (logically) need MCLK, while the RPi5 method for MCLK output is still not officially revealed - I am trying to finally get the info https://forums.raspberrypi.com/viewtopic.php?p=2346904#p2346904. Nevertheless the board should be trivial to modify to add an audio-mclk clock (the PCB is already prepared for that) and switch the HW mode-controlled WM8805 to master I2S. Then the other board would stay as is (slave) + RPi5 would use slave I2S configuration. Up to 4 SPDIF synchronous outputs should be easily available. Of course only at one fixed samplerate as the fs -> MCLK multiplier would be fixed.
 
I tried connecting a Raspberry Pi with CamillaDSP installed between the Wiim Ultra and miniDSP. All connections are via USB. The main issue now is the extremely low volume. And as I understand it, the problem isn't with CamillaDSP, but with the USB connection.
A USB connection cannot change volume, it's all digital. IMO you have some other issue there. Always add to your chain step by step - do not expect your whole chain running perfectly at first try.
 
If I connect it like this:
Wiim Ultra -> optical -> miniDSP -> optical -> DAC
then the volume is fine.

If I connect it like this:
Wiim Ultra -> USB -> miniDSP -> optical -> DAC
then the volume is a problem—it's too low, even when I turn the volume up to max.

In both cases, I control the volume from the Wiim.
 
OK, then maybe miniDSP offers some USB audio volume control feature to Wiim (would end up as a regular alsa control) and Wiim sets it too low. Or you have a different routing setup for optical and USB inputs in miniDSP.
 
If I connect it like this:
Wiim Ultra -> optical -> miniDSP -> optical -> DAC
then the volume is fine.

If I connect it like this:
Wiim Ultra -> USB -> miniDSP -> optical -> DAC
then the volume is a problem—it's too low, even when I turn the volume up to max.

In both cases, I control the volume from the Wiim.
Did you ensure that both connections have the same volume settings in both devices, Wiim and miniDSP? I think miniDSP now has configurable volume by input connection.
 
And the second question: will the Raspberry Pi4 have enough resources, and how much latency will there be? One of the sources is a TV, and I don't want to experience significant lag.
Yes, RPi 4B had enough power to do anything you wish for stereo. See this post about FIR power: https://www.diyaudio.com/community/threads/hypex-fusion-alternatives.423421/post-8124144 IIR filters require substantially less compute power.

As stated, delay is proportional to buffer sizes and maybe if you have crazy long FIR filters, they need delay for their function. If you keep things reasonable and the devices function properly, you can expect <10 ms delay from RPi+CDSP step. If you look at my few last posts in this thread, you can see that I'm successfully using very short latency configuration, but your devices are different.
 
Did you ensure that both connections have the same volume settings in both devices, Wiim and miniDSP? I think miniDSP now has configurable volume by input connection.
Yes, I double-checked the settings and they are absolutely the same for both the miniDSP optical input and the USB:
 

Attachments

  • 1762423879385.png
    1762423879385.png
    56.7 KB · Views: 30
Last edited:
delay is proportional to buffer sizes and maybe if you have crazy long FIR filters
Is there a way to see the current latency in the CamillaDSP console?
With my filter, the load on the Raspberry Pi4 is 25%. I'm getting excellent results and don't plan to add any more filters.

The CamillaDSP settings are as follows:
 

Attachments

  • 1762424231020.png
    1762424231020.png
    180.2 KB · Views: 31
I added a +18 dB gain filter, and it improved significantly. But I'm not sure how accurate this is :(

Regarding the resampling settings, the Wiim Ultra is set to output a fixed 24/48 bit rate. MiniDSP also works with these settings. And if I understand correctly, there's no need to change the resampling settings in CamillaDSP in this case.
 

Attachments

  • 1762427777465.png
    1762427777465.png
    254.4 KB · Views: 28
No resampling, but the rate adjust must be enabled for reliable operation.
 
Is there a way to see the current latency in the CamillaDSP console?
With my filter, the load on the Raspberry Pi4 is 25%. I'm getting excellent results and don't plan to add any more filters.

The CamillaDSP settings are as follows:
Not to my knowledge. I to would like to know the latency of different parts and pipelines in CamillaDSP. I got two pairs of output channels having different filters and I got no other way to know the latency difference than acoustic measurement with a mic. And that's funny when the speakers are far from each other and the pairs have different distance to listening spot. So I guess in my case knowing processing delay will not help, but would still be nice to know.

You can try lower chunksize, I use 128 because I don't use FIR and that's stable with my gear. Also queuelimit could be lower than default, like 1 or 2 if you are after a small latency. See: https://github.com/HEnquist/camilladsp?tab=readme-ov-file#devices for more info about these settings. If it crashes, you can just try raising the values until it's stable.
 
I found this Optical to USB converter:

Has anyone tried it?
That seems to be a new product. The website says it's identical to the UR23, but supports sample rates up to 192 kHz (instead of 96 kHz). For the UR23 mixed results were reported earlier in this thread (page 122). Many more TOSLINK-to-USB converters were discussed in thread Budget Standalone "Toslink > DSP > Toslink" with Camilladsp. Set up instructions for newbies. I made a summary of mainly that thread on my website when I was comparing converters.

I am using the Hifime S2 Digi to convert TOSLINK from my TV to USB for the Raspberry Pi 5 and that is working well in my relatively simple scenario. The TV outputs PCM stereo audio (not multichannel) with a fixed sample rate of 48 kHz. If the sample rate of your source can vary, you'll either need some auto detection (there seem to be some software solutions for CamillaDSP) or multiple configurations for CamillaDSP (one for each sample rate) to manually switch between. The S/PDIF / TOSLINK standard does not include communicating the sample rate or volume, so it's not the fault of the converters that they won't tell the USB side. What is the fault of some converters is that many don't behave well when the source stops outputting audio or changes the sample rate. Issues have been reported in the thread linked above.

Long story short: Converting TOSLINK to USB can work well, but there are some common issues unfortunately.
 
I tried connecting a Raspberry Pi with CamillaDSP installed between the Wiim Ultra and miniDSP. All connections are via USB. The main issue now is the extremely low volume.

I'm not entirely sure, but maybe ALSA also has a (software) volume setting for USB audio inputs. It doesn't hurt to check that. Run "alsamixer" on the command line on your Raspberry Pi and follow the on-screen instructions to select your audio input(s) (=capture devices) and check their volume. If that is the issue, you can change the volume there, quit and execute "sudo alsactl store" on the command line to store the new volume settings as the default when booting up.
 
Last edited:
Back
Top Bottom