It seems I have problem with stability with my CDSP V2 install.
CamillaDSP 2.0.1, pyCamillaDSP 2.0.0, Backend 2.0.0
Install where done over a working CDSP V1 on latest RPi-OS Lite 64-bit using this script
This error usally happens with system running over night with no music and when song changes. But stop also at mid song has now been registered. Restart CDSP and it can run everthing from 1 to 30+ tracks before music again stop and CDSP has to be restarted. Despite error message are related to the input I'm now in attempt to troubleshoot only running Volume in pipeline and no resampling.
Any idéa how to prossed troubleshooting this issue is much appreciated.
CamillaDSP 2.0.1, pyCamillaDSP 2.0.0, Backend 2.0.0
Install where done over a working CDSP V1 on latest RPi-OS Lite 64-bit using this script
This error usally happens with system running over night with no music and when song changes. But stop also at mid song has now been registered. Restart CDSP and it can run everthing from 1 to 30+ tracks before music again stop and CDSP has to be restarted. Despite error message are related to the input I'm now in attempt to troubleshoot only running Volume in pipeline and no resampling.
Any idéa how to prossed troubleshooting this issue is much appreciated.
@DEQ+TheEnd : Your config shows: capturing from Loopback timed by system clock, playing to USB timed by Amanero internal clock, rate adjustment not enabled. Two independent clocks - buffer issues on the capture or playback side will inevitable arise. My 2 cents - try enabling the rate adjustment.
For some reason the Loopback can misbehave with some values of buffersize and period. CamillaDSP V2 changed how these values are determined to make it work with more devices, but this seems to have made the loopback unhappy. But it's quite random, it works perfectly on some systems while giving issues on others. Not sure what to do about it.
@HenrikEnquist : Please do you have any specific info/code pointers? The above config has rate adjustment disabled and buffer issues will ensue, IIUC.
Thanks @phofman and @HenrikEnquist.
As I've already tried different mutiples of 256 for chunksize I will try to enable Rate adjust with default values and chunksize 1024 for 44.1KHz.
What is actually happening behind the scene with this enabled? Are samples dropped, or is this just tightening the buffer control?
Am I correct understanding changing to Stdin doesn't actually have any benefit over Alsa Loopback?
One for the wish list. What if default values where part of the help text associated with an item? In this case I'm curious about default values for rate adjust as initial test now have some dropouts and I don't actually know where to start any adjustment from.
As I've already tried different mutiples of 256 for chunksize I will try to enable Rate adjust with default values and chunksize 1024 for 44.1KHz.
What is actually happening behind the scene with this enabled? Are samples dropped, or is this just tightening the buffer control?
Am I correct understanding changing to Stdin doesn't actually have any benefit over Alsa Loopback?
One for the wish list. What if default values where part of the help text associated with an item? In this case I'm curious about default values for rate adjust as initial test now have some dropouts and I don't actually know where to start any adjustment from.
It's pretty weird. It worked well in 1.0.3, then buffers became smaller in 2.0.0 which seems to be worse. Then I increased the size again for 2.0.1, but it still not as good as 1.0.3.
The missing rate adjust should give frequent underruns, but it should recover nicely from those and there shouldn't be any EPIPE.
The missing rate adjust should give frequent underruns, but it should recover nicely from those and there shouldn't be any EPIPE.
No samples are dropped! It adjusts by fine-tuning the rate of the virtual clock of the loopback.
IMO the EPIPE on capture is not handled to recover https://github.com/HEnquist/camilladsp/blob/master/src/alsadevice.rs#L311 . IIUC EPIPE from readi means overrun which can easily happen if the rate is not adjusted - samples are read too slowly, the loopback runs too fast against the playback.
I use CamillaDsp as active crossover. Drivers are first measured via REW and the resulting params are entered into CamillaDsp running in a Pi5 driving Topping DM7+amps.
My question is, after all the configuration is done, how do I test the final result? I'd like to do a sweep with REW. Normally I'd have a Motu M4 connected to my PC into the amps directly. How do I connect the Motu M4 output to camillaDSP running in the Pi?
My question is, after all the configuration is done, how do I test the final result? I'd like to do a sweep with REW. Normally I'd have a Motu M4 connected to my PC into the amps directly. How do I connect the Motu M4 output to camillaDSP running in the Pi?
You can export the sweep from Rew as an audio file, and play it back with your normal playback player software while recording with Rew. If you have a spare usb sound card or interface with an analog input you could also plug that into the pi, and set CamillaDSP to capture from it. That way you can run as usual with the rew->m4 analog out -> pi analog in -> CamillaDSP etc.
Doesn't have to be a high quality device, pretty much anything with an input will do.
What puzzle me are how this error is happening over night with system running with no data on the input. Although I should mention CDSP will not start if the output device Amanero is powered down. Now hold on there, let me just test this before I post...
There you go. Part of mystery solved. If I power down the DAC CDSP do not recover from this and reboot is necessary. But error is different.
@DEQ+TheEnd that .service file starts camilladsp with the wait flag, -w. This means it won't exit on errors. Instead it stops and waits for a new config. It's better if it exists, because then systemd can restart it. I would recommend removing that -w. That way it will be able to recover from most errors automatically. Automatic restart is already enabled in the file.
I've personally never tried it, but RPi4 and RPi5 support USB On-The-Go on the USB-C power connector. I seem to remember seeing someone using it as a USB DAC pass-trough device for USB ADC. If this actually is possible one would connect RPi5 as output device on the REW computer, with M4 as recording device.
Some practical info here: https://raspberrypi.stackexchange.c...he-usb2-otg-port-on-the-rpi-4-model-b-located
This works very well, I'm running CamillaDSP on a pi4 like this in my own system.
See also this thread: https://www.diyaudio.com/community/threads/linux-usb-audio-gadget-rpi4-otg.342070/
Resampling here, there and everywhere?
I have never actually got to understand all the resampling possibilites with camilladsp.
Running rpi3b, (squeezelite) - camilladsp with simple prosessing. (some biquad Peak filters) Dac is soekris dam1021 with custom filters.
Music library consist of 16/24 44.1/48/88.2/96 and 192khz material. Some 352 and 384 and some dsd files.
I have the whole time used resampling in squeezelite to 96khz, and no resampling in camilladsp.
If I want to do all the resampling only in camilladsp and stop resampling in squeezelite what should I do? What should it say in /etc/asound.conf and in the "devices" settings in camilladsp gui?
Of course disable it in squeezelite.
I have never actually got to understand all the resampling possibilites with camilladsp.
Running rpi3b, (squeezelite) - camilladsp with simple prosessing. (some biquad Peak filters) Dac is soekris dam1021 with custom filters.
Music library consist of 16/24 44.1/48/88.2/96 and 192khz material. Some 352 and 384 and some dsd files.
I have the whole time used resampling in squeezelite to 96khz, and no resampling in camilladsp.
If I want to do all the resampling only in camilladsp and stop resampling in squeezelite what should I do? What should it say in /etc/asound.conf and in the "devices" settings in camilladsp gui?
Of course disable it in squeezelite.
Last edited:
@bambadoo - Problem with feeding CDSP mixed formats is that it doesn't support it out of the box. We first need to insert a program ALSA CamillaDSP "I/O" plugin CDSP that now take controll over and restart CDSP with correct sample rate.
https://github.com/scripple/alsa_cdsp
It's somewhat convelutet to implement and I'm not yet finished making useful script for it. As the plug take control over how CDSP start and we no longer use systemd service files to control and restart CDSP when error occurs.
I've ment to ask @HenrikEnquist how whell this plug handles errors as I've resently learned the -wait startup parameter cluttered up my initial v2 configuration. And fear this plug might give similar results when CDSP no longer are under systemd control?
https://github.com/scripple/alsa_cdsp
It's somewhat convelutet to implement and I'm not yet finished making useful script for it. As the plug take control over how CDSP start and we no longer use systemd service files to control and restart CDSP when error occurs.
I've ment to ask @HenrikEnquist how whell this plug handles errors as I've resently learned the -wait startup parameter cluttered up my initial v2 configuration. And fear this plug might give similar results when CDSP no longer are under systemd control?
Last edited: