search

HEnquist / camilladsp

A flexible cross-platform IIR and FIR engine for crossovers, room correction etc.
https://henquist.github.io/
GNU General Public License v3.0
564 stars 49 forks source link

Support for upsample filter #137

Open soumyabanerjee opened 3 years ago

soumyabanerjee commented 3 years ago

Presently I am using sox upsample filter (insert 0 value samples) to expand the bandwidth and follow it up with camilladsp FIR for interpolation with my custom coefficients. It would be great if upsampling can be done (with 64 bit float) in camilladsp itself. That way I can eliminate sox out of my pipeline altogether and just chain filters within camilladsp config file itself.

presently it is something like this: sox -c 2 -r 44100 -b 64 -e floating-point -t raw - -r 705600 -t raw - upsample 16 | camilladsp -l off

Love your work btw! CamillaDSP has replaced by brutefir pipeline ever since :)

HEnquist commented 3 years ago

I haven't thought of this but makes sense to include. And why not add decimation at the same time. I'm planning to release version 1.0 as soon as I'm sure the new CoreAudio backend is ready. Then this could go in the next version. The implementation will then go in the resampling library: https://github.com/HEnquist/rubato

soumyabanerjee commented 3 years ago

Thanks Henrik! Yeah having decimation along with upsample makes total sense. That said I am not sure including upsample filter in resampling library will be optimal - reason being users might want to use cascaded / multi-stage upsampling + interpolation (using custom FIR) for any number of reasons. At least I do so. So a processing pipeline like : 4x upsample -> interpolation -> 4x upsample -> interpolation I am not entirely sure if such a processing pipeline could be achieved if the proposed filter is part of rubato resampling module/library, unless you have bigger plans :)

HEnquist commented 3 years ago

All filters in a camilladsp pipeline must work at the same sample rate, it's not possible to use different rates in different parts of the pipeline. That's why the resampling is handled in the capture thread, before passing the audio data to the pipeline. Relaxing this would make the configuration much more complicated (and be a lot of work!), and I don't think the benefit would be large enough to make up for it.

I have started looking at how to add this to rubato. It seems pretty straightforward, shouldn't take very long once I get started.

soumyabanerjee commented 3 years ago

That's fine. I understand the constraints are there for a reason and making them more flexible would be more effort on your part - and likely not many would be interested in this feature. Coming from sox style of filter pipeline, it seemed natural to do so. Not a deal breaker though by any means. Even for me since I will continue to follow it up with another instance of camilladsp with a different up-sampling factor. Thanks again!