RPi4 + CamillaDSP Tutorial

[Wirrunna]

The new version is not working for me. No errors in journalctl for oled. If I replace it with the older version it works fine. I will be off for a 2 weeks and won't be able to test.

I confirm that the new version doesn't display anything.

Edit : It appears that some code is duplicated from line 139 to line 165, not going to look further.

 

[catch22]

Thank you very much @mdsimon2 for excellent tutorial, I was following and managed to set up, works perfect with both my old DAC Emotiva XDA-2, and with SMSL DL200.

Now, the question, this has been possibly raised before. not even once.

Is there a good way to use CamillaDSP with two or more DACs?
I understand that USB delays may be different and it may be PITA because different DACs process with different buffers..
But, what if two identical DACs are used?
I'm asking because nowadays 2 channel DACs becoming dirt cheap, while 4 or 8 channel for some reason are still few and expensive.
CamillaDSP + 2x SMSL SU1 or 2x Topping D10s could be very cost efficient for 2.2?

Is it a viable alternative to minidsp flex, or not?

 

[sarieri]

Thank you very much @mdsimon2 for excellent tutorial, I was following and managed to set up, works perfect with both my old DAC Emotiva XDA-2, and with SMSL DL200.

Now, the question, this has been possibly raised before. not even once.

Is there a good way to use CamillaDSP with two or more DACs?
I understand that USB delays may be different and it may be PITA because different DACs process with different buffers..
But, what if two identical DACs are used?
I'm asking because nowadays 2 channel DACs becoming dirt cheap, while 4 or 8 channel for some reason are still few and expensive.
CamillaDSP + 2x SMSL SU1 or 2x Topping D10s could be very cost efficient for 2.2?

Is it a viable alternative to minidsp flex, or not?

You can aggregate several devices under linux. But, it will not automatically align clocks across devices. In order for clocks to align across devices, each DAC needs to have spdif I/O or clock I/O. Two identical devices may have close alignment but it will never be precise.

Minidsp flex has a fixed latency comparing to camilladsp.

 

[phofman]

I understand that USB delays may be different and it may be PITA because different DACs process with different buffers..But, what if two identical DACs are used?

There are buffers in the alsa chain (software) and a FIFO in the USB receiver inside the DAC. Typically the alsa buffers are significantly longer than the device buffer. From this POV you can use different DACs and still have the overall buffers more or less same length for each.

But every async DAC has an internal clock which will always run at a slightly different speed, not matter if the same make of the DAC.

Also the data streams to two USB devices will inevitably start at slightly different moments, rather unlikely to fit the corresponding isochronous data packets into the same USB packet (which would be as close to the multichannel device "emulation" as one can get on USB).

 

[mdsimon2]

Thank you very much @mdsimon2 for excellent tutorial, I was following and managed to set up, works perfect with both my old DAC Emotiva XDA-2, and with SMSL DL200.

Now, the question, this has been possibly raised before. not even once.

Is there a good way to use CamillaDSP with two or more DACs?
I understand that USB delays may be different and it may be PITA because different DACs process with different buffers..
But, what if two identical DACs are used?
I'm asking because nowadays 2 channel DACs becoming dirt cheap, while 4 or 8 channel for some reason are still few and expensive.
CamillaDSP + 2x SMSL SU1 or 2x Topping D10s could be very cost efficient for 2.2?

Is it a viable alternative to minidsp flex, or not?

The only true way to use multiple DACs is to have them sync'd via a SPDIF / AES input using something like a miniDSP U-DIO8.

On Mac OS, the aggregate device + drift correction capability does OK for low frequencies but I am not sure I would trust it in the long term. Some threads related to this are shown below.

I’m searching for a cheap digital (SPDIF, “bit-perfect”) only delay device (I need ca. 25 ms delay)

What is the worst case scenario for de-synchronization between two DACs? I don't really know, but the OS is presumably sending frames to the DACs at the exact same time. Nope. In the usual audio mode the DAC requests the data packages based on its own internal clock.

www.audiosciencereview.com

VB Matrix

After three "10-hour" days with VB Matrix, I have not heard any dropouts/clicks/pops. Listening on the master or on the slave?

www.audiosciencereview.com

Multi-Channel, Multi-Amplifier Audio System Using Software Crossover and Multichannel-DAC

Hello friends, Let me share some hyperlinks to the remote threads where really interesting and "worthwhile-to-read" discussions are going on as of today (August 23 2023) and recently I myself have been partly participating: - What is your favorite house curve - The BEST rooms - looking for...

www.audiosciencereview.com

A miniDSP Flex is hard to beat for a 2.2 system. That being said, the MOTU M4 is not that different price wise than two Topping D10S and gives you a lot other capabilities for acoustic / electrical measurements.

Michael

 

[mdsimon2]

I confirm that the new version doesn't display anything.

Edit : It appears that some code is duplicated from line 139 to line 165, not going to look further.

Hmm...I downloaded the lgpio version I posted at it works fine on my CM4. I assume you guys are RPi5s? I haven't set up a display yet with my RPi5 but it is on the to-do list.

Michael

 

[Wirrunna]

Hmm...I downloaded the lgpio version I posted at it works fine on my CM4. I assume you guys are RPi5s? I haven't set up a display yet with my RPi5 but it is on the to-do list.

Michael

Yes, RPi 5.
I used a stacking header - https://www.adafruit.com/product/2223 - which (providing it was the right way around) made it easy to swap the display from a RPi4 to RPi5 when I was testing.

 

[mdsimon2]

Yes, RPi 5.
I used a stacking header - https://www.adafruit.com/product/2223 - which (providing it was the right way around) made it easy to swap the display from a RPi4 to RPi5 when I was testing.

Thought about this some more, I think on the RPi5 you need to use gpiochip4 instead of gpiochip0. Should just be a matter of changing "chip = sbc.gpiochip_open(0)" to "chip = sbc.gpiochip_open(4)".

I also have some C++ test code working with the OLED display using libgpiod. It is faster than lgpio but slower than rpi.gpio. I am sure my code has tons of inefficiencies but it runs very fast using rpi.gpio which suggests to me that the new gpiochip method may just be inherently slower. I'll see what I can to do optimize / clean it up and also play around with SPI to see if that is any better.

Michael

 

[terryforsythe]

Thank you for this thread mdsimon2.

I have ordered a Raspberry Pi 5 and a miniDSP MCHStreamer Kit to implement Chamilla DSP. I plan on using the MCHStreamer to connect to my active speakers via SPDIF.

If I can get the Tidal Connect App (on my Android tablet) and Logitech Media Server (on my NAS) both to stream via the Raspberry Pi, I will also use the Raspberry Pi as my streamer. Otherwise, I will connect a Chromecast dongle or a WiiM streamer to the MCHStreamer input. I bought the "kit" version of the MCH Streamer to give me that option should I need it.

I understand that I will need to re-flash the MCHStreamer with the firmware for the particular configuration I will be using. Beyond that and the instructions provided in Parts I - IV, are there any other suggestions? (I am already familiar with Linux - it is my daily driver on my home computer).

When researching I came across the moOde, which includes Chamilla DSP. moOde soon be releasing an ISO image for the Raspberry Pi 5. Do you recommend trying that?

 

[mdsimon2]

Only issue to be aware of is that the MCHStreamer has different clocking options, it can either use it's own internal clock or a clock derived from the SPDIF input. You can change the clocking via amixer or alsamixer. It's been a while since I used the MCHStreamer but I think it has issues if you attempt to start CamillaDSP with the clocking set to SPDIF input but no SPDIF input is present. Could probably write a simple script to always start using the internal clock and then switch to the SPDIF clock if you are using a SPDIF input.

These days I prefer to use the RPi as a simple DSP and use an external streamer (I use AppleTVs). If your capture and playback devices can use the same clock (MCHStreamer can do this as discussed above) this eliminates the need to use rate adjust or resampling in CamillaDSP.

Moode can work but in my experience it doesn't deal with external inputs (like SPDIF) well. If you can get everything you need from Moode it can be a good option. I am not a Tidal user so I can't speak to that.

Michael

 

[terryforsythe]

Thank you mdsimon2!!!

 

[Wirrunna]

Thought about this some more, I think on the RPi5 you need to use gpiochip4 instead of gpiochip0. Should just be a matter of changing "chip = sbc.gpiochip_open(0)" to "chip = sbc.gpiochip_open(4)".

I also have some C++ test code working with the OLED display using libgpiod. It is faster than lgpio but slower than rpi.gpio. I am sure my code has tons of inefficiencies but it runs very fast using rpi.gpio which suggests to me that the new gpiochip method may just be inherently slower. I'll see what I can to do optimize / clean it up and also play around with SPI to see if that is any better.

Michael

Michael, I'm away from home for a few days, but I am certain you are right about "chip = sbc.gpiochip_open(4)"

RPi4 + CamillaDSP Tutorial

Michael, And when I stop the service and run it manually - camilla@RPi5:~$ sudo service oled stop [sudo] password for camilla: camilla@RPi5:~$ camilla@RPi5:~$ camilla@RPi5:~$ sudo python3 ~/oled.py Traceback (most recent call last): File "/home/camilla/oled.py", line 2146, in main()...

www.audiosciencereview.com

I am embarrassed I did not remember this. Will test and confirm as soon as I get home.

 

[PO3c]

Recently got hold of RPi5 to replace my RPi3+ running LMS. As initial tests showed much improved response from Material Skin I dived into the topic of CPU speed and scaling governors.

Neither LMS or Squeezelite need anything better than RPi3 to play high rez audio but topic on hand here is server responce.

Scaling governors are/have presets responsible for how fast the CPU should run based on certain condition*. For RPi5 it select presets from 1.5GHz to 2.4GHz. While RPi3 run at 600MHz to 1.2GHz.

As it turns out my old RPi3 where much quicker to feed Material Skin a short burst of data when I set the scaling governor to performance. In prinsipple locking the CPU to max speed. While it before would serve at 600MHz for very short task it now burst at 1.2GHz. While RPi5 will do same at 1.5GHz when running under the default 'ondemand' governor.

Since I have my server and players on 24/7 I got the idea that rather have the CPU running full speed all the time I could let it go slow at nightime. And only have it running max speed in the hours I actually use the stereo. On Linux we can do this using crontab. Please see link below.

While I where at it I also made a Python script that can control the CPU speed depending if Squeezelite is playing or in pause modus.
Personally I'm not a believer in CPU on the player must run at constant speed as long at buffer underrun isn't a problem. But I know many like to lock the speed anyway. This script could add longevity to the RPi keeping the heat down when not in use.

LMS-helper-script/cpuspeed at main · StillNotWorking/LMS-helper-script

Tools to help maintain headless LMS devices for novice Linux users - StillNotWorking/LMS-helper-script

github.com

* Reference: https://www.kernel.org/doc/html/latest/admin-guide/pm/cpufreq.html

 

[mdsimon2]

While looking at example code for SSD1322 displays, I noticed they used a single GPIO write to send a byte to D0-D7. Looking at the documentation for lgpio, I realized it also has the ability to send a byte to multiple pins and to implement a group mask on that byte. I updated oled-lgpio using this approach and it is significantly faster, not quite as good rpi.gpio but much improved over the old version. Overall this gives me confidence that gpiochip performance can be acceptable and I imagine there are some other inefficiencies in the code that I can improve.

New version is attached for reference.

Michael

 

[mdsimon2]

Did a bit more optimizing of the oled python code and uploaded updated versions to main post. I think it is now about as good as I will get it.

There is still some performance difference between lgpio and rpi.gpio but it is now much less, I find it most noticeable when initially writing the display or clearing the display. Because the difference exists when clearing the display, I think the remaining issues are due to inherent differences between the two libraries.

Michael

 

[glc650]

While looking at example code for SSD1322 displays, I noticed they used a single GPIO write to send a byte to D0-D7. Looking at the documentation for lgpio, I realized it also has the ability to send a byte to multiple pins and to implement a group mask on that byte. I updated oled-lgpio using this approach and it is significantly faster, not quite as good rpi.gpio but much improved over the old version. Overall this gives me confidence that gpiochip performance can be acceptable and I imagine there are some other inefficiencies in the code that I can improve.

New version is attached for reference.

Michael

If one is currently using rpi.gpio (on an RPi 4 without any issues) is there any reason to switch to this?

 

[Wirrunna]

Michael,

Did a bit more optimizing of the oled python code and uploaded updated versions to main post. I think it is now about as good as I will get it.

There is still some performance difference between lgpio and rpi.gpio but it is now much less, I find it most noticeable when initially writing the display or clearing the display. Because the difference exists when clearing the display, I think the remaining issues are due to inherent differences between the two libraries.

Michael

Tried this new version (oled-lgpio_03142024.py) with "chip = sbc.gpiochip_open(0)" to "chip = sbc.gpiochip_open(4)" on RPi 5 and it works fine.

 

[mdsimon2]

If one is currently using rpi.gpio (on an RPi 4 without any issues) is there any reason to switch to this?

No, not currently. I imagine at some point in the near future rpi.gpio will no longer function, but for now it is OK.

Michael

 

[mdsimon2]

Apologize that I keep spamming this thread with display updates, but I made a few more changes to oled.py (dated 03152024 and uploaded to main thread).

I realized I could use the set_mode_sleep functionality to instantaneously clear the display after no changes had been made. Similarly, I can use set_sleep_mode to wait to turn on the display until all pixels have been written. Overall this results in a more professional appearance with no wiping effect.

Michael

 

[terryforsythe]

I have Camilla DSP working on my Raspberry Pi using the MCHStreamer kit.

Can anyone point me to a tutorial on how to create a convolution file for Camilla from an REW impulse response?

I tried using a .wav file like I do in SqueezeDSP for convolution, but Camilla DSP does not accept a .wav file. I then used Audacity to convert the .wav file to a .raw file before uploading to Camilla, but that did not work - the .raw file just caused the music to be garbled.