Ok, I updated the num-complex library and haven't tried with FFTW after that. Will take a look. Might mean that the FFTW binding also needs an update.
So. I did another test.
Not the sox2sox test.
Instead of feeding wav into the pipe towards squeeezelite. I know feed stream flacs.
That still shows the jumps on time stamps (not always) in the beginning, but somehow LMS seems to be able to resync the "playback time stamps" between LMS and squeezelite.
Bottom line. That's at least working so far. Good.
Obviously the primary issue is not yet solved.
Not the sox2sox test.
Instead of feeding wav into the pipe towards squeeezelite. I know feed stream flacs.
Code:
SOXOUTFT="-t flac -C 0 -b 24 -c 2"
$SOX -q "$track" -t wavpcm -b 24 - | $CAMILLA -v $camconfig | $SOX -q -t raw -b 24 -c 2 -L -e sign -r $newrate - $SOXOUTFT -That still shows the jumps on time stamps (not always) in the beginning, but somehow LMS seems to be able to resync the "playback time stamps" between LMS and squeezelite.
Bottom line. That's at least working so far. Good.
Obviously the primary issue is not yet solved.
Could you try something like this?
If I'm not mistaken, that should save a copy of what is piped back to LMS in checkme.wav. (I should probably set up LMS so I can try these things myself..)
Code:
$SOX -q "$track" -t wavpcm -b 24 - | $CAMILLA -v $camconfig | $SOX -q -t raw -b 24 -c 2 -L -e sign -r $newrate - $SOXOUTFT - | tee checkme.wavHi,
First, I would like to say thank you so much for developing and sharing this software. I find it fantastic !
I am using camilladsp in my system: Jrivers > camilla configured as a FIR digital cross over > Okto dac8PRO > 3 way active speakers. Both JRivers and camilladsp are running well on an RPI4. I also use my system for listening to music via Airplay (running on the RPI) and for watching video from a Roku (Roku > audio extractor SPDIF out > Okto dac8PRO SPDIF in > Okto dac8PROUSB out > RPI camilla). For video watching, I use IIR filters to avoid latency issues, its very nice that camilladsp can work with both types of filters.
At this time I simply manually start stop camilladsp and load the appropriate config file for the different applications. I plan to automate this so that switching airplay, Jrivers and Roku, is done via an IR remote control.
I have an idea/suggestion for the FIR filters. How about adding a frequency parameter for the FIR filter. The idea is to have camilladsp convert the provided impulse to the processing sample rate. I think this doable ? If it is, this means only one set of coefficients would needs to be provided by the user which would be compatible with all sampling rates. A single config file containing FIR filter coefficients could then be easily changed for use at any processing sampling rates without having to find and load the relevant coefficient files. I think this would make the use of FIR filters more consistent with IIR filters in the sense that they become independent of the processing sampling rate. Existing config files would be compatible if no FIR frequency parameter would default to the processing sampling rate.
Christian
First, I would like to say thank you so much for developing and sharing this software. I find it fantastic !
I am using camilladsp in my system: Jrivers > camilla configured as a FIR digital cross over > Okto dac8PRO > 3 way active speakers. Both JRivers and camilladsp are running well on an RPI4. I also use my system for listening to music via Airplay (running on the RPI) and for watching video from a Roku (Roku > audio extractor SPDIF out > Okto dac8PRO SPDIF in > Okto dac8PROUSB out > RPI camilla). For video watching, I use IIR filters to avoid latency issues, its very nice that camilladsp can work with both types of filters.
At this time I simply manually start stop camilladsp and load the appropriate config file for the different applications. I plan to automate this so that switching airplay, Jrivers and Roku, is done via an IR remote control.
I have an idea/suggestion for the FIR filters. How about adding a frequency parameter for the FIR filter. The idea is to have camilladsp convert the provided impulse to the processing sample rate. I think this doable ? If it is, this means only one set of coefficients would needs to be provided by the user which would be compatible with all sampling rates. A single config file containing FIR filter coefficients could then be easily changed for use at any processing sampling rates without having to find and load the relevant coefficient files. I think this would make the use of FIR filters more consistent with IIR filters in the sense that they become independent of the processing sampling rate. Existing config files would be compatible if no FIR frequency parameter would default to the processing sampling rate.
Christian
Thank you. To be clear for stderr I'm not recommended total silence, but rather only errors / warnings get printed just not normal operation info messages. Or perhaps a level (show me nothing, >= error, >= warn, >= info).
Henrik, it seems the extra_samples parameter is actually an explicit number of extra samples to add on the end of file input. Is that correct?
I was expecting a flag since Camilla is implementing the pipeline and knows all the filter lengths and how many extra samples are required to flush the filters.
I was expecting a flag since Camilla is implementing the pipeline and knows all the filter lengths and how many extra samples are required to flush the filters.
Hi! I have been thinking a little about this. The thing I got stuck on is how to resample the IR. It would of course be easy to use the resampler and just resample, but there are some drawbacks. The resampling adds a lowpass filter just below the Nyquist frequency. Not too bad when going down in sample rate, but does anyone want their 192kHz music limited to 20-ish kHz?
Maybe it's possible to use some tricks to improve things. I need to think more (and read up a little).
Just so that we're on the same page - it would be possible to generate a filter IR for say 192kHz and downsample that to use it at f.ex. 44.1kHz? Someone once told me that that has serious drawbacks blah blah blah, but I'm not in any position to dispute such claims, I'm simply lacking the mathematical background to prove otherwise. But it surely seemed strange at the time. So maybe you could confirm this.
Upsampling might be another thing but hey, if it's documented somewhere that you SHOULD generate your IRs at the highest used sample rate... You known where I'm going
Upsampling might be another thing but hey, if it's documented somewhere that you SHOULD generate your IRs at the highest used sample rate... You known where I'm going
I added a new --loglevel option that lets you select the level, including turning if off completely. I didn't remove the -v, but of course the two can't be used at the same time.
Yes it's the number of samples. Making it automatic would work when only using FIR and delay filters, but not that great when you add IIR. Also it gets nontrivial to calculate the number of samples needed for complicated pipelines.
The simple solution of just resampling the IR would work, both for going up and down in sample rate. But the resampling has two drawbacks:
- it adds a lowpass filter (at about 95% of Nyquist)
- it delays the IR and makes it longer (by something like 128 or 256 samples)
It can be debated how bad that is. In many cases they might be just fine. But I will experiment a bit, maybe it's possible to cheat and avoid the lowpass.
Well, I can only share my own listening experiences which I conducted maybe two weeks back. I played with LR4 LP filters at or around 20kHz (DSP SR was 96kHz back then). It was a somewhat more extensive test regarding phase shift at around 20kHz and if this is audible. My conclusions were that __I__ cannot hear any of that. So for simplicity reasons if this was possible and I'd have to input only one set of FIR filters I'd happily go with that, disregarding the steep LP at 95% nyquist. As always everything IMHO. The golden ears are free to disagree.
Convolution in time is multipying in frequency domain:
The Convolution Theorem and Application Examples - DSPIllustrations.com
So if FIR filter is multiplied with resampling lowpass filter, no added delay should be introduced and downsampling can be done without penalty?
(Because of the very high performance of the camilla DSP resampler)
Assuming resamling lowpass filter is not longer than FIR filter.
Last edited:
Should be:
-Transform FIR filter to frequency domain
-Multiply FIR and lowpass filter
-Transform the result to time domain
No added delay should be introduced and downsampling can be done without penalty?
(Because of the very high performance of the camilla DSP resampler)
Assuming resamling lowpass filter is not longer than FIR filter.
I may remember DSP theory wrong here, not 100% sure
-Transform FIR filter to frequency domain
-Multiply FIR and lowpass filter
-Transform the result to time domain
No added delay should be introduced and downsampling can be done without penalty?
(Because of the very high performance of the camilla DSP resampler)
Assuming resamling lowpass filter is not longer than FIR filter.
I may remember DSP theory wrong here, not 100% sure
Thanks. Am I just missing which branch this is in on github?
You could make -1 do the right thing for FIRs. But I'll just add an option to my cdsp alsa driver to take a number and a base sample rate to multiply the value up I guess.
Yes there will be a delay. The lowpass interpolation filter is linear phase (a windowed sinc in the time domain) so there is a little pre-ringing. The delay is needed to make space for this. It's not a big delay, just 128 samples or so.
I just pushed some changes to the develop branch, just update and you should have it.
The main problem with the auto calculation of the extra samples is to calculate the number. It's easy for a simple pipeline with just one stage of FIR filtering, but I would want it to work for all possible pipelines. Imagine a complicated pipeline with several stages of filtering with mixers in between. Then it would need to evaluate all the possible paths to find the longest one. It's doable but is it worth the effort?
@soundcheck: I also fixed the fftw compile errors. It compiles without errors, but I haven't tried actually running it yet. Could you try it?
Currently I am getting pops +
enable_rate_adjust is true
Rate adjust: is below 1 (0.99976796), but it changed recently, it was above 1.
I use this config for the PA: camilladsp-config/default.pa at master * HEnquist/camilladsp-config * GitHub
this for asound: camilladsp-config/asound.conf at master * HEnquist/camilladsp-config * GitHub
with just rate changed to 192000
Using the latest dev camilladsp compiled with alsa and websocket, Ubuntu 18.04.
What should I look for? Thanks
Code:
Prepare playback after buffer underrunRate adjust: is below 1 (0.99976796), but it changed recently, it was above 1.
I use this config for the PA: camilladsp-config/default.pa at master * HEnquist/camilladsp-config * GitHub
this for asound: camilladsp-config/asound.conf at master * HEnquist/camilladsp-config * GitHub
with just rate changed to 192000
Using the latest dev camilladsp compiled with alsa and websocket, Ubuntu 18.04.
What should I look for? Thanks