CamillaDSP - Cross-platform IIR and FIR engine for crossovers, room correction etc

I think I am making some progress.

Does my dietpi need a browser even though I will be using another machine to control it?

At the moment it has none and I wonder if that is a problem.

another question - what does this mean I need to do?
root@DietPi:~# cargo install --path /root/camilladsp2
Installing root v0.1.0 (/root/camilladsp2)
Updating crates.io index
Locking 55 packages to latest compatible versions
Compiling proc-macro2 v1.0.93
Compiling version_check v0.9.5
error: linker cc not found
|
= note: No such file or directory (os error 2)

error: could not compile proc-macro2 (build script) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
error: failed to compile root v0.1.0 (/root/camilladsp2), intermediate artifacts can be found at /root/camilladsp2/target.
To reuse those artifacts with a future compilation, set the environment variable CARGO_TARGET_DIR to that path.

What is 'cc'?

Installed build-essential and that seemed to be what was missing

THANKS
 
Last edited:
I have some questions about chuck size / buffers. Are the queues in the diagram below the same as the buffer? Or something different?

1739411602585.png


And what is queuelimit? Is it a limit on how large the buffer can get?

Michael
 
fb, you are a great asset to Mr. Enquist's great project.
Very kind of you, but my contribution pales in comparison to many others here 🙂
Does my dietpi need a browser even though I will be using another machine to control it?
No, your dietpi shouldn't need a browser - this is only required on the machine you use to access/control the GUI webpage.
another question - what does this mean I need to do?
root@DietPi:~# cargo install --path /root/camilladsp2
Looks like you're following the instructions for building/compiling camilladsp - this shouldn't be necessary as Henrik provides the pre-built executable program. Can you try following section 3 and 4 of these instructions instead - it spells out the exact command line instructions a bit easier: https://github.com/mdsimon2/RPi-CamillaDSP#3-install-camilladsp

From section 5 the instructions to install the GUI work fine, but have been superseded by a new install method for the GUI (https://github.com/HEnquist/camillagui-backend#download-a-complete-bundle). Try getting 3 + 4 above working first then we can attempt the GUI.
 
  • Like
Reactions: rickmcinnis
I have tried improving the buffer level measurement to include any chunks waiting in the channel. This seems to work well, and helps when using large values for target_level. It can even be larger than the buffer size, and the feedback still works as it should.
Henrik, please which commit is this implemented in? I could find only https://github.com/HEnquist/camilladsp/commit/2c0738ace4e0514e2f652c0730154399b7b8248a but cannot find where the waiting chunks are added to the buffer delay for averaging. Thanks!
 
I have some questions about chuck size / buffers. Are the queues in the diagram below the same as the buffer? Or something different?
The buffer is the Alsa device buffer, it's basically the shared space where the device and client read or write to exchange data. It's not shown in the diagram since it's an internal detail of the Alsa backend, The others don't have an exact equivalent. The way the Alsa playback backend works currently, this buffer should be large enough that a full chunk can be written to it.

The queues sit between the capture device and the pipeline, and between the pipeline and the playback device. They are message queues for passing data from one thread to another, where each message is one chunk. The blue boxes in the queues in the diagram are meant to show chunks waiting for the receiver to pick them up.

And what is queuelimit? Is it a limit on how large the buffer can get?
The queuelimit is a limit for how many chunks each queue can hold before it's full. If a queue gets full, the sender has to either wait for space to become available, or drop the chunk it's trying to send. Normally when running, the queues hold zero or one chunk each.
 
  • Like
Reactions: mdsimon2
  • Like
Reactions: phofman
I run the script again and it ended by saying successful - it looked like it did an upgrade watching the beginning - but I did not save the terminal window. Starting again and checking version, they are still all at 3.0.0.

Was there an upgraded script?

//
 
Updated again. Tried to start - but got this:

(base) M@MBP3 ~ % ~/camilladsp/bin/camilladsp -w -p 1234 --statefile /Users/MBPr/camilladsp/statefile.yml
2025-02-13 10:40:08.128004 INFO [src/bin.rs:781] CamillaDSP version 3.0.0
2025-02-13 10:40:08.128226 INFO [src/bin.rs:782] Running on macos, aarch64
2025-02-13 10:40:08.130533 ERROR [src/socketserver.rs:487] Failed to start websocket server: Address already in use (os error 48)


I've seen this many times before and my way out of it is a computer restart... Is there a faster/better way get out of it (os error 48)?

//
 
Was there an upgraded script?
Yes, you need the 3.0.1 script, otherwise it will just install 3.0.0 again.

I've seen this many times before and my way out of it is a computer restart... Is there a faster/better way get out of it (os error 48)?
Did you just shut down the old camilladsp process? I have noticed that macos sometimes is a bit slow to mark ports as free, but waiting a minute should solve it. Or rebooting of course.
 
OK I figured it out.

When quitting the terminal windows, terminal says "terminate process" - I always do this.

term.jpg


Entering:
lsof -nP -iTCP -sTCP:LISTEN | grep 5005 (netstat didn't work on my machine)
.... gave the pid for port user of 5005 and in this case it was "python3.13"

So closing the terminal quits camilla process but not process to which the port seem to belong to.

Killing the photon process, I could start camilla again without a computer restart but no change in revisions... hmm..

//