Camilladsp doesn't really integrate with coreaudio, instead it just opens one device for recording (BlackHole), and one for playback (your dac). CoreAudio offers several more advanced ways to hook into the audio stream but using thise doesn't fit well in a cross platform project like this.
The coreaudio api is large and quite complicated. Unfortunately the documentation from apple is very poor. The header files are a little better but a pain to navigate. I have mostly looked at the sources of other projects (such as cpal) to figure out how things are done. There may be some books that could help (I have not looked).
The coreaudio api is large and quite complicated. Unfortunately the documentation from apple is very poor. The header files are a little better but a pain to navigate. I have mostly looked at the sources of other projects (such as cpal) to figure out how things are done. There may be some books that could help (I have not looked).
In my oppinion it is best to let CamillaDSP resample any input sampling rate to one and the same sampling rate.
1. Because then you have the control of the resampling quality. The CamillaDSP config resampler quality options are already very refined by today, and even more quality options and variants are to come in V.2. Stay tuned an look forward ...
2. You can choose the resampled rate your DAC likes best.
3. You only need one set of filters for all incoming rates. If the incoming rate does not match the configured one, then you can let CamillaDSP crash, adapt the configuration to match the actually incoming audio and then let CamillaDSP restart again. No need for filter switching.
This approach works very well for me in an audio gadget Rpi: Audio_Host_USB_any_rate_out -> USB_Gadget_CamillaDSP_resampling_and_filtering -> SPDIF out -> DAC_in.
By the way: I would strongly advocate to try out a dedicated USB CamillaDSP gadget solution wherever possible. The current linux kernels (>5.18) now are fully functional, and the setup of a gadget is quite straightforward.
1. Because then you have the control of the resampling quality. The CamillaDSP config resampler quality options are already very refined by today, and even more quality options and variants are to come in V.2. Stay tuned an look forward ...
2. You can choose the resampled rate your DAC likes best.
3. You only need one set of filters for all incoming rates. If the incoming rate does not match the configured one, then you can let CamillaDSP crash, adapt the configuration to match the actually incoming audio and then let CamillaDSP restart again. No need for filter switching.
This approach works very well for me in an audio gadget Rpi: Audio_Host_USB_any_rate_out -> USB_Gadget_CamillaDSP_resampling_and_filtering -> SPDIF out -> DAC_in.
By the way: I would strongly advocate to try out a dedicated USB CamillaDSP gadget solution wherever possible. The current linux kernels (>5.18) now are fully functional, and the setup of a gadget is quite straightforward.
Last edited:
You mean a 90 degree shift for all frequencies? There is nothing like that in Camilladsp now, but you should be able to do it with a fir filter. I'm not aware of any way of it with iir filters that doesn't also change amplitude.
As Henrik says, use a FIR filter - see attachment 4 in this -
https://www.diyaudio.com/community/...m-correction-etc.349818/page-189#post-7213813
I have been away for a while and am getting back into my audio rig.
Has there been any issues with alsa_cdsp lately ?
I have started to get some intermittent audible glitches after upgrading my Debian install that I need to investigate.
I also see there has been patches made to bluez-alsa with respect to making pcm variables thread safe that should be investigated.
One bluez-alsa patch
I will post whatever I find.
Thanks much.
Has there been any issues with alsa_cdsp lately ?
I have started to get some intermittent audible glitches after upgrading my Debian install that I need to investigate.
Code:
6.1.0-0.deb11.5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.12-1~bpo11+1 (2023-03-05) x86_64 GNU/LinuxI also see there has been patches made to bluez-alsa with respect to making pcm variables thread safe that should be investigated.
One bluez-alsa patch
I will post whatever I find.
Thanks much.
If you want to change JUST phase, this will get you close, but there is some increase in phase in higher frequencies.
If anyone knows of a better way to do it in RePhase (without the high frequency roll), please chime in.
The xxx.RePhase file is in the attached zip file so you can change it to +/- 90, specify sampling rate, output format, # taps, etc. as you require.
Best process to compare FIR filters with "matching levels" ?
I just have installed CamillaDSP under Moode. I have several FIR filters to compare (min phase, lin phase, different corections...). How to "level match" the different filters so that they play at the same percieved level (rougthly , to reasonnably limit volume bias) ?
How to "measure" the filter "gain"? How to align that gain between the different filters?
I understand that this may not be CamillaDSP specific.
Best regards,
JMF
I just have installed CamillaDSP under Moode. I have several FIR filters to compare (min phase, lin phase, different corections...). How to "level match" the different filters so that they play at the same percieved level (rougthly , to reasonnably limit volume bias) ?
How to "measure" the filter "gain"? How to align that gain between the different filters?
I understand that this may not be CamillaDSP specific.
Best regards,
JMF
Create a config for one and each filter in Camilla. Measure with voltmeter at say 1khz for each filter (after preamp or maybe even at speaker terminal) - doesnt matter its just relative levels - and adjust attenuation in Camilla per config too match levels?
You want better than 10mV for less then 0,1 dB diff - and you do if for a relevant comparison
http://www.sengpielaudio.com/calculator-gainloss.htm
//
You want better than 10mV for less then 0,1 dB diff - and you do if for a relevant comparison
http://www.sengpielaudio.com/calculator-gainloss.htm
//
Well, if the FR is not straight then all bets are off - on the other hand - if so, something else if dubious to say the least...
But, if you do it like that and hear some differences - well, there you have it - yous spotted it ;-D great - misson accomplished.
IRs are normalise to 1 - so no...
//
But, if you do it like that and hear some differences - well, there you have it - yous spotted it ;-D great - misson accomplished.
IRs are normalise to 1 - so no...
//
@HenrikEnquist is it possible to have re-usable fragments of a YML file for IIR filters (aka include similar to FIR filters specifying a path to parameters)?
What I want to do, is create my 6 channel crossover filters once and also pipeline, but have different YML files for an upstream EQ setting, before going to the crossover.
At the moment, I have to repeat the crossover filters and pipeline in each YML for a different EQ.
What I want to do, is create my 6 channel crossover filters once and also pipeline, but have different YML files for an upstream EQ setting, before going to the crossover.
At the moment, I have to repeat the crossover filters and pipeline in each YML for a different EQ.
There was a similar question recently: https://github.com/HEnquist/camilladsp/issues/276#issuecomment-1493112896
The yaml standard doesn't have any built-in way to include another yaml file. And I don't want to add features to load other files, the fir filter coefficients are already causing enough trouble with relative vs absolute paths etc.
The yaml standard doesn't have any built-in way to include another yaml file. And I don't want to add features to load other files, the fir filter coefficients are already causing enough trouble with relative vs absolute paths etc.