Can I attenuate SPDIF with CDSP and a Motu MK5 or would I still need to buy one of those Hifime capture cards?
-
WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. 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!
RPi4 + CamillaDSP Tutorial
- Thread starter mdsimon2
- Start date
OP
- Thread Starter
- #1,082
If you are using the SPDIF input of the Motu UL Mk5 then, yes, you can attenuate via CDSP and avoid intersample over clipping. The reason for this is that the UL Mk5 does not have an ASRC on the input.
The only issue with this is that if you are using the SPDIF input the MOTU UL Mk5 needs to be clocked via SPDIF. If you are also using a USB input you will need to switch the clock source on the Motu via the front panel from SPDIF to internal. Not a huge deal but it does prevent source switching via remote or CDSP GUI only.
Michael
Hi,
Can one run two camilladsp processes simultaneously and independently? If yes, how?
This is what I am trying to achieve:
Audio via i2s input -> camilladsp process 1 -> i2s output -> i2s to spdif -> external device -> usb -> camilladsp process 2 (on the same raspberry pi) -> usb -> dac
Both process 1 and 2 are quite simple, I am not worried about the pi being able to do it. Process 1 is just a fixed volume control setting that can be fixed or adjusted from time to time via terminal or via a script and left running in the background, nothing that I will have or want to change regularly.
Some latency is acceptable.
Thanks for any advice!
Can one run two camilladsp processes simultaneously and independently? If yes, how?
This is what I am trying to achieve:
Audio via i2s input -> camilladsp process 1 -> i2s output -> i2s to spdif -> external device -> usb -> camilladsp process 2 (on the same raspberry pi) -> usb -> dac
Both process 1 and 2 are quite simple, I am not worried about the pi being able to do it. Process 1 is just a fixed volume control setting that can be fixed or adjusted from time to time via terminal or via a script and left running in the background, nothing that I will have or want to change regularly.
Some latency is acceptable.
Thanks for any advice!
somebodyelse
Major Contributor
- Joined
- Dec 5, 2018
- Messages
- 3,753
- Likes
- 3,050
I expect it could be done. Create separate config files for each process, and separate init or systemd files to launch them using their respective configs. This generally works (running multiple squeezelite instances for example) so long as there isn't a shared resource involved. Using camilladsp just for volume control seems overkill though - seems like something better done with alsa config.
Thank you @somebodyelse
How would you call different processes from different systemd files? Do you need to create two different camilladsp folders (say camilladsp1 and camilladsp2) install camilladsp in both of them and then simply one systemd file for each or two or can two different systemd files call the same camilladsp folder? From your post i understand the second option, just want to confirm i understood right. (sorry if I use the wrong terminology, as you can see i am a bit lost)
In general even if it is an overkill, the effort of yet learning something new can justify using camilladsp and call it a day, but if it is just a matter of setting up a 3 line script and improve latency all in one shot, well, why not.
*edit: could i just use alsamixer for the card to which i output the i2s audio to adjust the signal level down as desired? Does the card need to have volume control capabilities for this to work or is it done by alsa?
How would you call different processes from different systemd files? Do you need to create two different camilladsp folders (say camilladsp1 and camilladsp2) install camilladsp in both of them and then simply one systemd file for each or two or can two different systemd files call the same camilladsp folder? From your post i understand the second option, just want to confirm i understood right. (sorry if I use the wrong terminology, as you can see i am a bit lost)
I am all ears. I am just familiar with Camilladsp. Can you recommend something to read about that?
In general even if it is an overkill, the effort of yet learning something new can justify using camilladsp and call it a day, but if it is just a matter of setting up a 3 line script and improve latency all in one shot, well, why not.
*edit: could i just use alsamixer for the card to which i output the i2s audio to adjust the signal level down as desired? Does the card need to have volume control capabilities for this to work or is it done by alsa?
Last edited:
CDSP (apart of its web UI) is a single binary/exe file with a single config file. You need only one instance of the exe file and two config files, each with appropriate settings.
If you enable the CDSP websockets server, each running instance will have to use a different port (or address/port) - see --port parameter in https://github.com/HEnquist/camilladsp#command-line-options .
If you enable the CDSP websockets server, each running instance will have to use a different port (or address/port) - see --port parameter in https://github.com/HEnquist/camilladsp#command-line-options .
In the meantime i also found how to set a software volume control for a card that does not have one, which i believe is going to be my case. So maybe no need for a second camilladsp process. I hope it works:
alsa.opensrc.org
Alsa Opensrc Org - Independent ALSA and linux audio support site
Alsa Opensrc Org - Independent ALSA and linux audio support site
Does anyone know if a Real Time kernel will improve the performance of the camilladsp? I’m not really concerned about the latency, but camilladsp sometimes have a pops/clicks especially when I run some simple commands in ssh. This seems to only happen in USB gadget mode so I guess the pops comes from the UAC2Gadget input.
somebodyelse
Major Contributor
- Joined
- Dec 5, 2018
- Messages
- 3,753
- Likes
- 3,050
I doubt it. I assume you're talking about Ubuntu making a kernel with the PREEMPT_RT patch set generally available. This doesn't magically make everything more responsive - software needs to be specifically written to use the real-time scheduling capabilities, and to do it correctly. https://www.theregister.com/2023/02/20/ubuntu_realtime_capable_edition/ has some explanation of some of the issues, as do the various explanatory articles from Ubuntu themselves.
Last edited:
Make sense. Thank you
radix
Major Contributor
- Joined
- Aug 1, 2021
- Messages
- 1,398
- Likes
- 1,335
You could try using "nice <command>" to give it a lower scheduling priority, or up the priority of CDSP in the kernel.
@sarieri : Just 2 cents: What CPU frequency governor do you use? I would suggest to try a frequency governor with fixed frequency, so that frequency switching is avoided. Switching frequency could cause delays which in the USB gadget driver are undesired (CPU must service every single USB microframe). The SSH access event could force the CPU to higher frequency, triggering the delay.
You can try the highest frequency your RPi allows, and if it helps, try lower values to decrease heat.
What is your gadget bInterval (microframe period)?
You can try the highest frequency your RPi allows, and if it helps, try lower values to decrease heat.
What is your gadget bInterval (microframe period)?
Will try. Thank you so much for the advice.
I tried to set the cpu at a fixed frequency and it seems like the pops are gone. Gonna need more testing though. I haven't really googled out a way to check current gadget microframes...Can you shed some light on it?
That would be excellent news!
While playback running, check file /proc/asound/USB_CARD_NAME/stream0 on a linux USB host (not the gadget). For UAC2 it should (also) list the current audio device microframe period.
Well, I’m on windows right now. Might need to install ubuntu on my laptop to check that. But anyway, it seems like keeping the cpu at a fixed frequency is the key.
Thank you! Helps a lot.
AlfaNovember
Member
Many thanks to @HenrikEnquist for the software and to @mdsimon2 for the tutorial. Just adding into the record here - I've used the instructions to build a 2-way crossover, using an Odroid C4 board, Armbian 23.02.2 Jammy (alsa w/ loopback), and a MOTU M4. It boots up smoothly, just a few minor clicks, and appears nicely in Roon, including volume control via roon-extension-cdsp. CPUs sits at one or two percent playing 44/16 with highpass/lowpass and volume filters. The performance the rig is simply astounding.
I'm still working on getting shairport-sync working; I had initially moved Camillagui up to port 6000, which failed with a blank page. Turns out node.js has a list of restricted ports, and moving to port 5150 put me back in business. Next item is to tell shairport that I want to use hw:Loopback device.
The final step will be to figure out how to stream REW sweeps through the system and subsequently generating EQ transforms. It's been an enjoyable project, and again, my gratitude to all who made it possible.
I'm still working on getting shairport-sync working; I had initially moved Camillagui up to port 6000, which failed with a blank page. Turns out node.js has a list of restricted ports, and moving to port 5150 put me back in business. Next item is to tell shairport that I want to use hw:Loopback device.
The final step will be to figure out how to stream REW sweeps through the system and subsequently generating EQ transforms. It's been an enjoyable project, and again, my gratitude to all who made it possible.
Similar threads
