Well, my mention of pipewire was with regard to low latencies and jackd https://www.diyaudio.com/forums/pc-...sa-loudspeaker-crossover-dsp.html#post6787743 . It was not meant to use it to run camilladsp with.
I would wait a bit with PW support, it's still a very moving target, IMO. The RedHat guys over here in Brno are very excited about it but I have my doubts about time it will take to feature-parity with PA.
I would wait a bit with PW support, it's still a very moving target, IMO. The RedHat guys over here in Brno are very excited about it but I have my doubts about time it will take to feature-parity with PA.
Last edited:
Sorry I've been busy with other stuff a few days..
Yes!
The active configuration is a symlink. Lets say you have a config stored at /home/pi/camilladsp/configs/lots_of_bass.yml, and you have a symlink at /home/pi/camilladsp/configs/jespers_current.yml. Then you have set your systemd config to start camilladsp with /home/pi/camilladsp/configs/jespers_current.yml.
Now, if you select a different config file in the gui, and click to make it default, it will update the symlink to point at the new file instead. So next time you reboot, camilladsp will start with the new file.
Yes!
The default config is what the web interface starts with if there is no active config. It's just a way to provide a customized default one, tailored to a particular application (like moOde for example).
The active configuration is a symlink. Lets say you have a config stored at /home/pi/camilladsp/configs/lots_of_bass.yml, and you have a symlink at /home/pi/camilladsp/configs/jespers_current.yml. Then you have set your systemd config to start camilladsp with /home/pi/camilladsp/configs/jespers_current.yml.
Now, if you select a different config file in the gui, and click to make it default, it will update the symlink to point at the new file instead. So next time you reboot, camilladsp will start with the new file.
The current Fedora version uses Pipewire instead of Pulse. That's actually running on the machine I'm typing this on, works just fine. I don't know of any other distro that has made the switch (but I also haven't looked).
When camilladsp is running it's always measuring the input level so you can read it over the websocket interface. Is that what you need?
My apologies, phofman!
I agree with your thoughts on pipewire. It's going to be really useful when its development pace settles a little!
@HenrikEnquist, would it be possible to add the jack backend into the standard build? I think there's a good use case for it. I was able to get it all running nicely by doing the following:
- Start the JACK server:
Code:# jackd -d alsa -p 128 - (Re)start the CamillaDSP service:
Code:# systemctl restart camilladsp - Make the necessary JACK connections for the configuration I had:
Code:jack_connect system:capture_1 cpal_client_in:in_0 jack_connect system:capture_2 cpal_client_in:in_1 jack_connect system:playback_1 cpal_client_out:out_0 jack_connect system:playback_2 cpal_client_out:out_1 jack_connect system:playback_3 cpal_client_out:out_2 jack_connect system:playback_4 cpal_client_out:out_3 jack_connect system:playback_5 cpal_client_out:out_4 jack_connect system:playback_6 cpal_client_out:out_5
After that, sound was working without issue. I used the web-based CamillaGUI-backend to get the loudspeaker crossover configured, and I tested it by muting some channels on the mixer, and sending the config to the DSP.
Great stuff 🙂 Now I just need to build the speakers, measure the room response, and get the FIR filters in the pipeline!
This has come up several times now. It's a pity that Roon doesn't support PCM devices. It's really limiting!
As phofman already mentioned, adding that is trivial. If enough people bug them about it, maybe they will listen eventually? Worth a try at least.
I was hoping that camilladsp was running as an ALSA 'sound server' by itself, so that it would process the live sound going through the audio device without any further need. After reading more on ALSA (honestly, I should have known better long before this), I realised that JACK made the most sense in my particular context.
For now I prefer to keep Jack out of the standard builds. Adding it means that the jack libraries must be installed to run, even if the jack backend isn't being used. cargo makes is quite easy to build a custom one.
If there are many who what that, I could add another binary build with Jack. Let me know!
Should keep you busy for a day or two 😀
Hi Henrik...
Thank's for the good answer's.
I'am myself busy... working on some PicorePlayer/TinyCore .tcz's to have the pycamilladsp, pycamilladsp-plot and camillagui ran as real harcore 😎 in-ram extensions, instead of saving the hole python/sitepackages as i used to when installing this.
I'am running the very good MoOdeaudio on my mainstereo right now, but i cannot resist making a new SuperPlayer at least for myself
Jesper.
I have published binaries for the first preview of v1.0.0 here: Release 1.0.0-alpha1 * HEnquist/camilladsp * GitHub
The main thing is the new CoreAudio backend, but there are also some general improvements. And hopefully not too many new bugs 🙂
The main thing is the new CoreAudio backend, but there are also some general improvements. And hopefully not too many new bugs 🙂
HenrikEnquist,
Does Pipewire and/or Kernel 5.14 with the lower latency USB drivers offer any noticeable improvements ?
I am running Debian 11 and optimistically awaiting 5.14 to appear in buster-backports.
Thanks much.
Kernel 5.14 brings major improvements to the USB gadget mode, which is great if you use that. I don't know anything about the lower latency USB drivers.
Pipewire seems to use less CPU than Pulse. But I have mostly used it for normal desktop use, not really any music listening (only to check that it can be used with camilladsp). Most normal users probably don't notice anything different with pipewire.
Pipewire seems to use less CPU than Pulse. But I have mostly used it for normal desktop use, not really any music listening (only to check that it can be used with camilladsp). Most normal users probably don't notice anything different with pipewire.
Hi here... (piCorePlayer / piCore only)
I really like the Gui, and i find it fun to "play" with actually.
Then for a long time i really wanted to make a real in ram .tcz solution for installing it, instead of cluttering the sitepackages up with pip3 install, i created 17 .tcz with the dependicies for the camillagui + freind's 🙂
I know it's a bit offtopic so please take a look at my github here:
GitHub - Lykkedk/SuperPlayer-v8.0.0--CamillaGUI-v0.6.0: SuperPlayer-CamillaGUI .tcz extensions the right way of doing it
Jesper.
I really like the Gui, and i find it fun to "play" with actually.
Then for a long time i really wanted to make a real in ram .tcz solution for installing it, instead of cluttering the sitepackages up with pip3 install, i created 17 .tcz with the dependicies for the camillagui + freind's 🙂
I know it's a bit offtopic so please take a look at my github here:
GitHub - Lykkedk/SuperPlayer-v8.0.0--CamillaGUI-v0.6.0: SuperPlayer-CamillaGUI .tcz extensions the right way of doing it
Jesper.
Rust just got experimental support for many more Neon instructions. That's exactly the stuff needed for adding Neon support to RustFFT! So I have done that, basically by translating the SSE code. It will take a little time before this is ready to be included in a RustFFT release, mostly because of the early state of the Rust Neon support. Even the current nightly release of the compiler is too old to build this!
The first results were a bit discouraging. It turns out that the Neon unit on the Cortex A72 of the RPi4 is quite slow. It only helps for 32-bit floats, while 64-bit runs at the same speed as without Neon. Here is a comparison for power-of-2 lengths:
Switching to a more powerful CPU makes things look much better. This is the same benchmark from a Neoverse N1 on an Amazon EC2 virtual machine (similar to a Cortex A76):
Once the standard nightly compiler can be used, it would be great to run the benchmark on an Apple M1 too. Could someone here help out with that? The whole process only takes 15 minutes or so.
The first results were a bit discouraging. It turns out that the Neon unit on the Cortex A72 of the RPi4 is quite slow. It only helps for 32-bit floats, while 64-bit runs at the same speed as without Neon. Here is a comparison for power-of-2 lengths:
Switching to a more powerful CPU makes things look much better. This is the same benchmark from a Neoverse N1 on an Amazon EC2 virtual machine (similar to a Cortex A76):
Once the standard nightly compiler can be used, it would be great to run the benchmark on an Apple M1 too. Could someone here help out with that? The whole process only takes 15 minutes or so.
Variable log file name in camilladsp.service daemon
Hi
As a command line instruction I can successfully run
But if I put this instuction in camilladsp.service
I get the following error
Is there a way to do this?
I'm trying to use $date to create a unique filename for the log file, but any other variable labelling would be fine.
BTW I want to do this because I'm finding that camilladsp.service keeps stopping and restarting for reasons which are not yet apparent to me, so I want to look at the logfile from the previous session ... but of course it will have been overwritten.
Thanks
Hi
As a command line instruction I can successfully run
Code:
/usr/local/bin/camilladsp -a0.0.0.0 -p5000 -g-30 --logfile "/usr/local/etc/camilladsp/[B]log$(date +"%FT%H%M").txt[/B]" -ldebug /usr/local/etc/camilladsp/config2x192.yml
Code:
ExecStart=/usr/local/bin/camilladsp -a0.0.0.0 -p5000 -g-30 --logfile "/usr/local/etc/camilladsp/log$(date +"%FT%H%M").txt" -ldebug /usr/local/etc/camilladsp/config2x192.yml
Code:
/etc/systemd/system/camilladsp.service:9: Failed to resolve unit specifiers in /usr/local/etc/camilladsp/log$(date +%FT%H%M).txt:I'm trying to use $date to create a unique filename for the log file, but any other variable labelling would be fine.
BTW I want to do this because I'm finding that camilladsp.service keeps stopping and restarting for reasons which are not yet apparent to me, so I want to look at the logfile from the previous session ... but of course it will have been overwritten.
Thanks
I've been running CamillaDSP from the command line this morning with the time reference in the log file name , and after a couple of hours it just crashed with this error message captured in the logfile:
Code:
Sep 27 10:47:01.755 WARN Capture failed, error: ALSA function 'snd_pcm_readi' failed with error 'EPIPE: Broken pipe', module: camillalib::alsadevice
Sep 27 10:47:01.759 ERRO Capture error: ALSA function 'snd_pcm_readi' failed with error 'EPIPE: Broken pipe', module: camilladsp
Sep 27 10:47:01.760 DEBG Wait for playback thread to exit.., module: camilladsp
Sep 27 10:47:01.977 DEBG Restarting with new config, module: camilladsp
Sep 27 10:47:01.977 DEBG Wait for config, module: camilladsp
Sep 27 10:47:01.978 DEBG No config and not in wait mode, exiting!, module: camilladspTry increasing the chunksize!
You can also experiment with the "retry_on_error" setting on the capture device.
You can also experiment with the "retry_on_error" setting on the capture device.
Thanks. I'm starting with the chunksize going from 4096 to 8192 for 192kHz sample rate. Will try the other options if I need to.
Might this be worth putting in the Troubleshooting section of your excellent documentation?
Henrik, I finally got a chance to fire up the full Camilla experience with my new speaker build. You may recall I struggled toget Camilla working on a Pi Zero only to discover it's simply not powerful enough.
Right now it's only running 4th order L-R high and lowpass without any other filtering and my best guess at relative gain values. I hope to get to some measurement and fine tuning this week.
Even without any adjustment, the sound is super clean. You wouldn't know there's a raspberry pi and some cheap USB dongles involved...
specs (after many years of storage):
Mind the dust:
The whole test setup system:
The Pi 3 B+ with 3 USB sound dongles:
The venerable Sherwood RD-6108 which can act as a 6 channel direct pass through amplifier (and is perfect for Camilla DSP):
Right now it's only running 4th order L-R high and lowpass without any other filtering and my best guess at relative gain values. I hope to get to some measurement and fine tuning this week.
Even without any adjustment, the sound is super clean. You wouldn't know there's a raspberry pi and some cheap USB dongles involved...
specs (after many years of storage):
- Peerless OT19NC00 ring radiator without faceplate
- Dayton Audio H45E 4.5" x 4.5" Elliptical Waveguide
- Adire Audio Extremis 6.8 midwoofer
- 0.62 cu ft box tuned to 36.6 Hz (on-paper F3 of 39Hz)
Mind the dust:
The whole test setup system:
The Pi 3 B+ with 3 USB sound dongles:
The venerable Sherwood RD-6108 which can act as a 6 channel direct pass through amplifier (and is perfect for Camilla DSP):