Thanks for spotting! I added them now in thereadme for the develop branch.
A little update. I have been working on trying to optimize the RustFFT library, and have managed to get some quite nice improvements.
This shows the speed of my new version compared to the current release, for all lengths 1-1024:
The really large improvements are for prime lengths, which aren't really used by CamillaDSP. The power-of-two lengths were already very good so I have not managed to improve them. The benefit for CamillaDSP is when using the synchronous resampler, where conversions between the 44.1 and 48kHz groups should become about 40% faster.
I also made a beta release of CamillaDSP v0.5.0:
Release v0.5.0 beta1 * HEnquist/camilladsp * GitHub
New features:
I added a build job for armv8 (aka 64-bit arm, aarch64). This should run on raspberry pi:s that have a full 64-bit OS. I have not tried it yet, so any feedback is welcome.
The "develop" branch of pyCamillaDSP library is also updated for this new version. The gui will be ready soon.
This shows the speed of my new version compared to the current release, for all lengths 1-1024:
The really large improvements are for prime lengths, which aren't really used by CamillaDSP. The power-of-two lengths were already very good so I have not managed to improve them. The benefit for CamillaDSP is when using the synchronous resampler, where conversions between the 44.1 and 48kHz groups should become about 40% faster.
I also made a beta release of CamillaDSP v0.5.0:
Release v0.5.0 beta1 * HEnquist/camilladsp * GitHub
New features:
- Add RMS and Peak measurement for each channel at input and output.
- Add a Volume filter for volume control.
- Add exit codes.
- Adapt check output to be more suitable for scripts.
- Search for filter coefficient files with relative paths first in config file dir.
I added a build job for armv8 (aka 64-bit arm, aarch64). This should run on raspberry pi:s that have a full 64-bit OS. I have not tried it yet, so any feedback is welcome.
The "develop" branch of pyCamillaDSP library is also updated for this new version. The gui will be ready soon.
That's a huge speed improvement, hats off! I really like the incremental steps by which you are adding new algorithms and improving the existing ones in RustFFT. BTW there do you get inspiration for the highly-optimized algorithms, is it from the existing highly-optimized C libraries (fftw) or do you look up and study the theoretical papers?
Thanks! I have been looking everywhere, including other libraries and papers. Papers are good for the theory but are usually difficult to use for actually implementing stuff, for that having some working code is really good.
FFTW was the first place I looked, but the interesting bits are written in difficult-to-read OCaml that generates difficult-to-read C code. Not helpful. FFTS and pocketfft are easier and have the Bluestein algorithm I wanted. In the end I used this: fourier/bluesteins.rs at master * calebzulawski/fourier * GitHub
It's very well written in Rust, so much easier to read (for me at least). I could easily port the entire thing to RustFFT.
For the length 3, 5 and 7 butterflies, I did not find anything useful. After thinking a little I just did it myself. It's just about doing DFT while avoiding repeating the same calculations. I described it here: RustFFT/butterflies.rs at 5and7 * HEnquist/RustFFT * GitHub
The 5-point one starts on line 310 and 7-point at 544.
This work is just awesome. I really appreciate the fact that you follow "papers" closely. Papers may not compile and run but that's where you (usually) find the proofs that things actually do what they're meant to ;-)
I've got Camilla on 3 pis. On the zero it runs, but alsa tends to underun ;-) I'll try v5 right away.
Congrats!
I've got Camilla on 3 pis. On the zero it runs, but alsa tends to underun ;-) I'll try v5 right away.
Congrats!
Yes you can use it for system wide DSP. That can be accomplished in several ways. For example via an Alsa loopback: GitHub - HEnquist/camilladsp-config: Help for setting up CamillaDSP, example config files etc
Or with this really neat Alsa plugin: GitHub - scripple/alsa_cdsp: ALSA plugin for Camilla DSP
CamillaDSP can do multichannel DSP. It's easy if you use the same computer/RPi as playback source and DSP. But getting a digital multichannel signal from a TV or such (as you wrote about in the other thread) is not so easy, I don't have any solution for that. Capturing an analog multichannel signal with a multichannel sound card would of course work, but then you would still need an AVR.
Or with this really neat Alsa plugin: GitHub - scripple/alsa_cdsp: ALSA plugin for Camilla DSP
CamillaDSP can do multichannel DSP. It's easy if you use the same computer/RPi as playback source and DSP. But getting a digital multichannel signal from a TV or such (as you wrote about in the other thread) is not so easy, I don't have any solution for that. Capturing an analog multichannel signal with a multichannel sound card would of course work, but then you would still need an AVR.
Didn't think about that, but yes that should work just fine!
Ffmpeg can apparently capture from an alsa device. Then decode, and pipe the data to CamillaDSP for processing. And then from there to the dac. This would need the asynchronous resampler to keep the two independent clocks in sync, but a Pi should be able to do that for 6 channels at 48kHz.
Ffmpeg can apparently capture from an alsa device. Then decode, and pipe the data to CamillaDSP for processing. And then from there to the dac. This would need the asynchronous resampler to keep the two independent clocks in sync, but a Pi should be able to do that for 6 channels at 48kHz.
Thanks for the tips and advice. It seems DTS format is found on bluray and DVD, things like Netflix are encoded in dolby formats which would be by primary use, so that's puts a stop to using a PI4 as a AVR decoder for my use situation.
As I don't really understand much of linux programming but am prepared to try and learn if its feasible, could someone answer on the feasibility of the below.
As camillaDSP can do system wide DSP is it possible to combine this with Volumio (I use Spotify connect playback) on a PI4?
Additionally would it be possible to take the 2.0 optical audio stream from a TV and run that through the PI4 and CamillaDSP to give 2.0 DSP to things like Netflix?
The goal is to have DSP applied to Spotify Connect and 2.0 audio from a TV using a PI4 without the need to switch software, maybe to have some auto detection applied to the optical input on the PI4.
My Assumption is if CamillaDSP is set to perform systemwide DSP then any audio input if configured correctly would have DSP settings applied, so the optical-in DSP processing side would be covered and should be doable for someone of my limited ability.
Then to perform the second part it would be necessary to install Volumio on this modified kernel if that's the right term (again my assumption is CamillaDSP is essentially like a foundational change to the OS and you can build / install something on top it like Volumio if you know what you are doing)
As stated my knowledge of Linux and programming is limited, but id be interested to know if the above is possible through configuration or would this require programming? If the latter then its probably beyond my capability.
As I don't really understand much of linux programming but am prepared to try and learn if its feasible, could someone answer on the feasibility of the below.
As camillaDSP can do system wide DSP is it possible to combine this with Volumio (I use Spotify connect playback) on a PI4?
Additionally would it be possible to take the 2.0 optical audio stream from a TV and run that through the PI4 and CamillaDSP to give 2.0 DSP to things like Netflix?
The goal is to have DSP applied to Spotify Connect and 2.0 audio from a TV using a PI4 without the need to switch software, maybe to have some auto detection applied to the optical input on the PI4.
My Assumption is if CamillaDSP is set to perform systemwide DSP then any audio input if configured correctly would have DSP settings applied, so the optical-in DSP processing side would be covered and should be doable for someone of my limited ability.
Then to perform the second part it would be necessary to install Volumio on this modified kernel if that's the right term (again my assumption is CamillaDSP is essentially like a foundational change to the OS and you can build / install something on top it like Volumio if you know what you are doing)
As stated my knowledge of Linux and programming is limited, but id be interested to know if the above is possible through configuration or would this require programming? If the latter then its probably beyond my capability.
I do not see the difference between software decoding DTS and AC3 (Dolby Digital), how does the RPi4 matter?
Apologies I didn't realise AC3 was Dolby, this is means in theory then its possible to use mplayer, ffmpeg and other tools as you mentioned. It would be interesting to test to see how much latency is introduced.
I found this GitHub - jakemoroni/audio_async_loopback: Real-time S/PDIF PCM/AC3 capture and playback repo today and it looks like an interesting solution to the idea of receiving ac3 and sending it to Camilla.
The age of of the repo and the comments in the readme suggest it’s far from mature but it’s an option for the adventurous.
The age of of the repo and the comments in the readme suggest it’s far from mature but it’s an option for the adventurous.
New beta of 0.5.0 is up!
Changes:
- Add ShibataLow dither types.
- Add option to write logs to file.
Additionaly, the linux amd64 binary was previously built on Ubuntu 19.10. This release has reached EOL, and I have switched the build over to Ubuntu 20.4. This probably means some libraries have been updated, and could cause trouble on some older systems. The best is of course updating to a recent system. If that is not an option, then you will have to compile it yourself (which really isn't difficult with Rust and Cargo).
Changes:
- Add ShibataLow dither types.
- Add option to write logs to file.
Additionaly, the linux amd64 binary was previously built on Ubuntu 19.10. This release has reached EOL, and I have switched the build over to Ubuntu 20.4. This probably means some libraries have been updated, and could cause trouble on some older systems. The best is of course updating to a recent system. If that is not an option, then you will have to compile it yourself (which really isn't difficult with Rust and Cargo).