One more thing: you're probably better off with installing a graphical environment anyways as for now only pulseaudio backend will be supported, no ALSA. And running camilladsp and pulseaudio as a service can be tricky because of permissions (pulseaudio socket).
I will have PaXoverNG start the camilladsp binary by itself, so having PaXoverNG with --start parameter in the autostart programs will get you there way faster without fiddling with service and daemon configurations...
I will have PaXoverNG start the camilladsp binary by itself, so having PaXoverNG with --start parameter in the autostart programs will get you there way faster without fiddling with service and daemon configurations...
As of right now this information is pretty outdated. Had a play with the alsa-cdsp plugin today and it seems there is a nice way to make camilladsp start automatically on demand with a proper configuration file. Also it should be possible to retain a alsa-sink for pulseaudio that plays to the alsa-cdsp plugin, also retained across reboots. As I'm figuring out things as I try them out, things might change again. But I always will have the end user experience in mind and try to keep things as KISS as possible
One more benefit of the current approach using alsa-cdsp: Strictly speaking pulseaudio will not even be a requirement to run PaXoverNG anymore, the input can be switched to ALSA only. Resampling to the output device's sampling rate is then handled by the amazing rubato resampler library used by camilladsp (instead of soxr for pulseaudio, which IMO is also pretty perfect). But that concept might be interesting for people who want to run headless systems without pulseaudio / ALSA only...
Watch this space, it's pretty much a moving target right now...
Last edited:
Don't give Henrik a hard time guys
It's amazing enough that he managed to build such a stable and versatile DSP backend!
GUI programming is for software-plumbers equiped with rolls of unixoid-gaffer-tape like I am and not for real programmers
EDIT: AND he is a nice guy. On top of that he answered all of my (possibly dumb) questions in way less than 24h, accepted feature requests etc...
It's amazing enough that he managed to build such a stable and versatile DSP backend!
GUI programming is for software-plumbers equiped with rolls of unixoid-gaffer-tape like I am and not for real programmers
EDIT: AND he is a nice guy. On top of that he answered all of my (possibly dumb) questions in way less than 24h, accepted feature requests etc...
Last edited:
No worries!
Even more curious now with the new PI Zero 2 W out!
I have one on my desk, intended for paxor. Very curious if it will be powerful enough. It is such a cool form factor. My rpi 3 benefits quite a lot from zram, so whether ram is enough seems the biggest question.
I finally got round to creating a fresh microSD card with Raspberry Pi OS and trying out the new Pi Zero 2 W with paxor.
Downloading and installing updates was pretty fast. I opened Chromium to navigate to the installation instructions of paxor. Chromium is very slow on the Zero 2 W. It wasn't fun. Of course there are other ways to do it than directly on the Zero 2 W, but I thought it was interesting to try out the desktop experience. Not doing that again.
The installation of paxor and necessary python modules was quick and easy. Paxor loaded fine, I built a circuit (input-parametric EQ-output) and inserted it in pulseaudio. The log showed green letters, so far so good. I also played music with VLC and I saw no visual signs of problems. The VLC time bar was moving smoothly and at a plausibele pace, CPU load was low, memory use below 150MB, temp stayed at 55 degrees Celsius.
There is no header on the Zero 2 W, so I have not been able to quickly put on an amplifier HAT and actually hear it. I tried recordings systemaudio, but didn't succeed. I think I'll plug it into my AV-receiver over HDMI, for a quick verification of operation.
And now I guess I should think back to childhood soldering and try to solder that header on.
Downloading and installing updates was pretty fast. I opened Chromium to navigate to the installation instructions of paxor. Chromium is very slow on the Zero 2 W. It wasn't fun. Of course there are other ways to do it than directly on the Zero 2 W, but I thought it was interesting to try out the desktop experience. Not doing that again.
The installation of paxor and necessary python modules was quick and easy. Paxor loaded fine, I built a circuit (input-parametric EQ-output) and inserted it in pulseaudio. The log showed green letters, so far so good. I also played music with VLC and I saw no visual signs of problems. The VLC time bar was moving smoothly and at a plausibele pace, CPU load was low, memory use below 150MB, temp stayed at 55 degrees Celsius.
There is no header on the Zero 2 W, so I have not been able to quickly put on an amplifier HAT and actually hear it. I tried recordings systemaudio, but didn't succeed. I think I'll plug it into my AV-receiver over HDMI, for a quick verification of operation.
And now I guess I should think back to childhood soldering and try to solder that header on.
@Tfive Dear Jürgen - I would like to ask the question, which is not fully related to newest development, but to your development concept in general. Perhaps it was addressed earlier but I struggle to find it in so many pages of the thread.
The question is about measuring speaker haracteristics. With "normal" audio systems we have input to the amp and microphone in front of the speaker. This is not the case here and I am wondering how to use software such SpeakerWorkshop or HolmImpulse ? I imagine the option woud be to take another USB card provide testing signal to input and from terminal loop-back the signal to the xover output in the system. Is it the right way? How do you do it?
The question is about measuring speaker haracteristics. With "normal" audio systems we have input to the amp and microphone in front of the speaker. This is not the case here and I am wondering how to use software such SpeakerWorkshop or HolmImpulse ? I imagine the option woud be to take another USB card provide testing signal to input and from terminal loop-back the signal to the xover output in the system. Is it the right way? How do you do it?