hi, I have audio in three rooms which will eventually total 29 outputs. Presently using DCX2496 crossovers and rather than acquiring another of these often problematic devices for the channel expansion I‘m looking to replace them all with CamillaDSP.
I usually but not always have audio playing in only one room at a time. In the interest of keeping the configuration file(s) more manageable and to perhaps reduce the total processing load, is it possible to invoke more than one simultaneous Camilla instance each with it’s own separate configuration (i.e. one for each room)?
I’m on a Mac and use RA’s “Loopback” for routing so it’s easy to create/route individual multi-channel pseudo-devices for each room‘s ins and outs.
BTW: Really impressive piece of work - thank you!
I usually but not always have audio playing in only one room at a time. In the interest of keeping the configuration file(s) more manageable and to perhaps reduce the total processing load, is it possible to invoke more than one simultaneous Camilla instance each with it’s own separate configuration (i.e. one for each room)?
I’m on a Mac and use RA’s “Loopback” for routing so it’s easy to create/route individual multi-channel pseudo-devices for each room‘s ins and outs.
BTW: Really impressive piece of work - thank you!
Last edited:
Update on the above:
seems there is no problem (so far) with running a second instance of camilladsp with a different configuration with different devices leaving off the -p option on the second instance.
Tried adding -p with a different port number and -a option with an unused address within the local subdomain results in a “cannot assign requested address (os error 49)”. Guessing this might be a permissions thing but not sure how to proceed.
So the question becomes how to run and connect to multiple instances of the backend?
cheers, Louis
seems there is no problem (so far) with running a second instance of camilladsp with a different configuration with different devices leaving off the -p option on the second instance.
Tried adding -p with a different port number and -a option with an unused address within the local subdomain results in a “cannot assign requested address (os error 49)”. Guessing this might be a permissions thing but not sure how to proceed.
So the question becomes how to run and connect to multiple instances of the backend?
cheers, Louis
Last edited:
The parameter -a specifies an address to bind the listening socket to. It must be an existing address assigned to one of the device interfaces, not any address within the ethernet segment. The purpose is to limit the listening port to that specific address - typically localhost or LAN/WAN addresses for a router.
Avoiding the parameter means the process will listen on the specified port on all available addresses/interfaces of the device. IMO that's what you want - each process requires a different port, of course.
Got it working. The secret sauce is in the backend configuration file ~/camilladsp/gui/config/camillagui.yml which among other things specifies the mapping between the camilladsp -p port and the server's http port. Since main.py its started from the ~/camilladsp/gui directory and is hardcoded to load the config from ./config/camillagui.yml, creating multiple gui_someroom directories and modifying the configs to map unique -p ports to http ports and then starting separate backend instances from each gui_someroom directory has it working.
The same file also specifies where the backend should look for unique statefiles and logfiles which should match what's declared in each camilladsp startup command (-s and -o respectively).
~/camilladsp/gui_room1/config/camillagui.yml :
------
camilla_host: "0.0.0.0"
camilla_port: 1234 <-----
bind_address: "0.0.0.0"
port: 5005 <-------
...
statefile_path: "~/camilladsp/statefile_room1.yml"
log_file: "~/camilladsp/camilladsp_room1.log"
...
-------
room1 server available at http://127.0.0.1:5005
room1 frontend startup:
camilladsp config_room1.yml -p 1234 -s ~/camilladsp/statefile_room1.yml -o ~/camilladsp/camilladsp_room1.log
-------------------------------------------------------
~/camilladsp/gui_room2/config/camillagui.yml :
-----
camilla_host: "0.0.0.0"
camilla_port: 1235 <-----
bind_address: "0.0.0.0"
port: 5006 <-------
...
statefile_path: "~/camilladsp/statefile_room2.yml"
log_file: "~/camilladsp/camilladsp_room2.log"
...
-------
room2 server available at http://127.0.0.1:5006
room2 frontend startup:
camilladsp config_room2.yml -p 1235 -s ~/camilladsp/statefile_room2.yml -o ~/camilladsp/camilladsp_room2.log
As a request it would be helpful to allow a backend command line option to specify an alternate backend config file to use when starting up. This would eliminate the (apparent) need for the multiple gui directories.
Looks promising but much more testing to be done.
The same file also specifies where the backend should look for unique statefiles and logfiles which should match what's declared in each camilladsp startup command (-s and -o respectively).
~/camilladsp/gui_room1/config/camillagui.yml :
------
camilla_host: "0.0.0.0"
camilla_port: 1234 <-----
bind_address: "0.0.0.0"
port: 5005 <-------
...
statefile_path: "~/camilladsp/statefile_room1.yml"
log_file: "~/camilladsp/camilladsp_room1.log"
...
-------
room1 server available at http://127.0.0.1:5005
room1 frontend startup:
camilladsp config_room1.yml -p 1234 -s ~/camilladsp/statefile_room1.yml -o ~/camilladsp/camilladsp_room1.log
-------------------------------------------------------
~/camilladsp/gui_room2/config/camillagui.yml :
-----
camilla_host: "0.0.0.0"
camilla_port: 1235 <-----
bind_address: "0.0.0.0"
port: 5006 <-------
...
statefile_path: "~/camilladsp/statefile_room2.yml"
log_file: "~/camilladsp/camilladsp_room2.log"
...
-------
room2 server available at http://127.0.0.1:5006
room2 frontend startup:
camilladsp config_room2.yml -p 1235 -s ~/camilladsp/statefile_room2.yml -o ~/camilladsp/camilladsp_room2.log
As a request it would be helpful to allow a backend command line option to specify an alternate backend config file to use when starting up. This would eliminate the (apparent) need for the multiple gui directories.
Looks promising but much more testing to be done.
