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

Jump to Latest
#5,563
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:
#5,564
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
 
#5,565
rickmcinnis said:
fb, you are a great asset to Mr. Enquist's great project.
Click to expand...
Very kind of you, but my contribution pales in comparison to many others here 🙂
rickmcinnis said:
Does my dietpi need a browser even though I will be using another machine to control it?
Click to expand...
No, your dietpi shouldn't need a browser - this is only required on the machine you use to access/control the GUI webpage.
rickmcinnis said:
another question - what does this mean I need to do?
root@DietPi:~# cargo install --path /root/camilladsp2
Click to expand...
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
#5,566
HenrikEnquist said:
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.
Click to expand...
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!
 
#5,567
mdsimon2 said:
I have some questions about chuck size / buffers. Are the queues in the diagram below the same as the buffer? Or something different?
Click to expand...
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.

mdsimon2 said:
And what is queuelimit? Is it a limit on how large the buffer can get?
Click to expand...
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
#5,568
  • Like
Reactions: phofman
#5,569
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?

//
 
#5,570
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)?

//
 
#5,572
TNT said:
Was there an upgraded script?
Click to expand...
Yes, you need the 3.0.1 script, otherwise it will just install 3.0.0 again.

TNT said:
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)?
Click to expand...
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.
 
#5,578
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..

//
 
You must log in or register to reply here.
Top Bottom