@kerux: What Henrik means is that your need to make sure your USB host is playing before you start capture in CDSP. Since it's a major condition, there are several wrappers for the usb audio gadget which monitor the gadget device status and start CDSP after playback starts on the host - the easiest to configure is specialized gadget -> CDSP tool https://www.diyaudio.com/community/threads/sample-rate-switcher-for-camilladsp.403054/
As a side note - IMO using plughw for the gadget device may result in expensive resampling in alsa if CDSP opens the device with non-native rate - something better to avoid. Just using hw:Gadget... should do.
As a side note - IMO using plughw for the gadget device may result in expensive resampling in alsa if CDSP opens the device with non-native rate - something better to avoid. Just using hw:Gadget... should do.
If you don't like the behavior of your IIR filters near 20kHz all you need to do is increase the sample rate. The problem is that 20kHz is very close to the Nyquist frequency at 48kHz or especially 44.1kHz. Use at least 96kHz and you get a lot of room between 20kHz and Nyquist (48kHz for SR=96kHz).
Bear with me while I'm confusing myself. Current service file with v1 reads
ExecStart=/usr/bin/camilladsp -p 1234 /home/pi/camilladsp/active_config.ymlWould this be leading to success with v2?
ExecStart=/usr/bin/camilladsp -p 1234 -s /home/pi/camilladsp/state.ymlHow is this file formatet? Is it the complete config or simply a pointer? If pointer can it use relative path to the statefile itself?
The statefile is a small yml file that holds the path to the config and the mute+volume settings. Just run the camilladsp command in a terminal, it will create the statefile if it doesn't exist.
Thanks Henrik. Sorry but something might have changed or I'm still confusing myself. Here I'm expecting the statefile to be created in the same directory as camilladsp is running from.
Below are output from running alpha5 from home directory:
Bash:
$ ./camilladsp
CamillaDSP 2.0.0-alpha5 and then the helpfile
$ ./camilladsp -s
error: The argument '--statefile <statefile>' requires a value but none was supplied
$ ./camilladsp -s statefile.yml
2023-10-31 10:51:29.495805 INFO [src/bin.rs:683] CamillaDSP version 2.0.0-alpha5
2023-10-31 10:51:29.495886 INFO [src/bin.rs:684] Running on linux, aarch64
2023-10-31 10:51:29.495981 WARN [src/statefile.rs:29] Could not read statefile 'statefile.yml'. Error: No such file or directory (os error 2)
Last edited:
Then I figured it might actually need a config file to actually start. So I downloaded example v2 yml from here https://github.com/HEnquist/camilladsp/tree/next20
Now camilladsp create an emty file named 'dummy' as found as filename the config file. Is this the statefile in question?
Now camilladsp create an emty file named 'dummy' as found as filename the config file. Is this the statefile in question?
Actually, that is what I also thought, until a forum user demonstrated that with lots of IIR all-pass blocks you can perform phase/group-delay EQ. There is an algorithm for computing the set of AP filters to perform the phase or group delay EQ called "Frequency Domain Least Squares" (FDLS) and a paper by M.Lang on it:
https://www.semanticscholar.org/pap...c059c5ace6d6ca74a19ffa25fbdac10fd9332500?p2df
It might take tens of stages, but it CAN be done (surprisingly). For an example see:
https://www.diyaudio.com/community/threads/how-to-correct-phase-for-iir-filters.353377/post-6178132
Of course you will need to to know group delay of the system you wish to equalize, but this can be obtained via measurement.
Also, I should add that you can design an FIR group delay EQ filter just from the group delay response itself, and some intuition on how you want to equalize it. I have done this in the past. Once you obtain the group delay you need to add to the system in order for its group delay response to be flat above some frequency, you are able to compute the phase response, and therefore you know the response you want to construct because the amplitudes will all be 1 (e.g. no amplitude change). Given the phase and amplitude vs frequency you can then construct the FIR filter using the usual techniques. Then do a quick check by computing the response of the FIR filter to make sure that any ringing is minimal or absent, which will depend on how many taps are used, etc. just like with any other filter.
Last edited:
I think I'll classify that as theoretically possible but too impractical to implement in practice 😋