Ohoj!
Would it all be possible to assign a "nick-name" to these sources and destinations? After they are created... like little help tabs for the memory 🙃
Every time I enter this pretty simple 2 way setup to do something I just cant seem to remember what is left and right as well as highs and lows
//
Would it all be possible to assign a "nick-name" to these sources and destinations? After they are created... like little help tabs for the memory 🙃
Every time I enter this pretty simple 2 way setup to do something I just cant seem to remember what is left and right as well as highs and lows
//
Maybe. It's something I would like to add at some point. So far I haven't come up with a workable way to implement it (meaning one that makes life easier rather than harder). A nickname is only valid for a part of the pipeline. As soon as there is a mixer, the channels and names change. It gets quite messy..
Camilla doing well
https://www.audiosciencereview.com/...sp-measurements-and-rising-noise-floor.42383/
//
https://www.audiosciencereview.com/...sp-measurements-and-rising-noise-floor.42383/
//
Daemon statuses reported by systemctl when CamillaDSP is not playing: Started and Deactivated/activating
I've run into some issues with the Node-RED routine I use to control CamillaDSP's volume, mute and configuration becoming unreliable. I'll come back to that, but the issue seems to stem from the CamillaDSP daemon being in two different states before playback starts. I want to clarify whether my understanding about the two different states is correct.
I should also state that I have an external USB soundcard for playback (RME ADI-2 Pro FS R) which is powered down until needed.
Deactivated/activating
If my RME is off during booting of the RPi4 or restating of the daemon, then the CamillaDSP tries to start up, but "Cannot get card index for Pro53791076" (the RME) so retries every second until it can find the RME when it is eventually powered on. During this time the status reported by systemctl alternates between Deactivated and activating:
Which status systemctl reports seems to depend simply on where it is in the second-long reactivation process when the status is requested.
Started
This is the happy state of affairs (when my Node-RED routine works) that arises when CamillaDSP is paused. It's what I see after the RME is powered up, or after the RME is powered down after pausing playback through CamillaDSP.
Have I got this right?
If I've understood this correctly then I can make adjustments to my Node-RED and Harmony routines. Node-RED needs to test GetState until CamillaDSP responds and reports "Paused" before trying to send a new config or change volume or mute. And I need to add a fixed delay to the command to power down the RME so that playback can be paused before CamillaDSP crashes because it's still processing when the soundcard 'disappears'.
If I am right, there are two other things that CamillaDSP might be able do to make it more resilient. The first is to retain the card index data for the soundcard and assume that it won't have changed since the previous time it was used. The second would be to exit gracefully when the soundcard 'disappears'.
I've run into some issues with the Node-RED routine I use to control CamillaDSP's volume, mute and configuration becoming unreliable. I'll come back to that, but the issue seems to stem from the CamillaDSP daemon being in two different states before playback starts. I want to clarify whether my understanding about the two different states is correct.
I should also state that I have an external USB soundcard for playback (RME ADI-2 Pro FS R) which is powered down until needed.
Deactivated/activating
If my RME is off during booting of the RPi4 or restating of the daemon, then the CamillaDSP tries to start up, but "Cannot get card index for Pro53791076" (the RME) so retries every second until it can find the RME when it is eventually powered on. During this time the status reported by systemctl alternates between Deactivated and activating:
ubuntu@ubuntu:~$ sudo systemctl status camilladsp
● camilladsp.service - CamillaDSP Daemon
Loaded: loaded (/etc/systemd/system/camilladsp.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2023-02-26 08:10:48 UTC; 8ms ago
Main PID: 311219 (camilladsp)
Tasks: 1 (limit: 9190)
Memory: 160.0K
CPU: 5ms
CGroup: /system.slice/camilladsp.service
└─311219 /usr/local/bin/camilladsp -a0.0.0.0 -p5000 -g-36 --logfile /usr/local/etc/camilladsp/log.txt -ldebug /usr/local/etc/camilladsp/Roon.yml
Feb 26 08:10:48 ubuntu systemd[1]: Started CamillaDSP Daemon.
Feb 26 08:10:48 ubuntu camilladsp[311219]: ALSA lib confmisc.c:165
Feb 26 08:10:48 ubuntu systemd[1]: camilladsp.service: Deactivated successfully.
Which status systemctl reports seems to depend simply on where it is in the second-long reactivation process when the status is requested.
Started
This is the happy state of affairs (when my Node-RED routine works) that arises when CamillaDSP is paused. It's what I see after the RME is powered up, or after the RME is powered down after pausing playback through CamillaDSP.
Have I got this right?
If I've understood this correctly then I can make adjustments to my Node-RED and Harmony routines. Node-RED needs to test GetState until CamillaDSP responds and reports "Paused" before trying to send a new config or change volume or mute. And I need to add a fixed delay to the command to power down the RME so that playback can be paused before CamillaDSP crashes because it's still processing when the soundcard 'disappears'.
If I am right, there are two other things that CamillaDSP might be able do to make it more resilient. The first is to retain the card index data for the soundcard and assume that it won't have changed since the previous time it was used. The second would be to exit gracefully when the soundcard 'disappears'.
Yes that seems correct. You could use udev to avoid the endless retry loop, and simply start camilla when the usb device appears.
You should stop camilladsp before turning off the device, the paused state isn't enough. And camilladsp doesn't crash when the device disappears, it logs an error and exists. If you run with the wait flag, "-w", then it will go back to waiting for a new config instead of exiting.
How would remembering the card id help? It's still not possible to open a card that doesn't exist. It will simply fail on the next step instead.
CamillaDSP already exists as gracefully as it can when a card disappears. The only exception to that is when it's paused and the playback device disappears (and only with Alsa). When paused, it doesn't try to talk to the playback device at all, so there is no way to know that the device has gone missing. It won't notice until processing resumes, and then it will fail and exit right away. Powering off and then on the device while in paused state will not work, the device needs to be re-opened before playback can continue.
Thanks @HenrikEnquist . Your pointers helped me get to the bottom of the issue and correct some errors in my original control routine that had always been there, but only recently exposed by my kids regularly using some different streaming sources . So in case anyone else stumbles with setting up a USB DAC that they power down when not in use, I've changed the standard setup in the following areas:
- Implement step 5 of Henrik's guide on "Configuring and running CamillaDSP" to use udev to start camilladsp.service when the USB DAC powers on (or is plugged in)
- Disable camilladsp.service from automatically starting on boot (sudo systemctl disable camilladsp)
- Edit the unit file and:
- in the ExecStart line use the -w flag and remove any reference to the startup configuration, so that when udev starts camilladsp up, camilladsp just sits waiting patiently for the config to be sent to it
- delete/comment out the Restart and RestartSec entries, which I think needs to be done so that when camilladsp is told to Exit and stop, it sits there and waits to be restarted
- In my Node-RED control routine, on startup, poll the websocket every 0.1s with "GetState" until camilladsp responds that it is up and running before sending down SetConfigName, Reload, and whatever else to the camilladsp websocket
- In the control routine, sending Exit to the websocket before powering down the USB DAC
A simple
stupid solution could be to just make a FIR filter with a given windowed length from the IIR filters combined tranfer functionFor those lucky users with clock cycles to spare and to low electricity bill
That's pretty much what can be done with reasonable effort, and I agree it's pretty useless.
I'm trying to install CarmilliaDSP on my Windows 10 machine and have stalled. I believe I have successfully installed Rust, as I can get the Hello World app to work. I assume I'm doing something dumb during the next steps. Here are my commands and results...
Microsoft Windows [Version 10.0.19045.2728]
(c) Microsoft Corporation. All rights reserved.
C:\Users\Mike>set RUSTFLAGS=-C target-cpu=native
C:\Users\Mike>cargo build --release
error: could not find
C:\Users\Mike>
Sorry, but I don't know what I'm doing wrong. Do I need to be in a specific directory?
Thanks, Mike
Microsoft Windows [Version 10.0.19045.2728]
(c) Microsoft Corporation. All rights reserved.
C:\Users\Mike>set RUSTFLAGS=-C target-cpu=native
C:\Users\Mike>cargo build --release
error: could not find
Cargo.toml in C:\Users\Mike or any parent directoryC:\Users\Mike>
Sorry, but I don't know what I'm doing wrong. Do I need to be in a specific directory?
Thanks, Mike
I have an issue which is I find rather weird. I use camilladsp on a rpi 4 with an HDMI-receiver as D/A. Generally it works very well but with one issue, after a while while playing the channel mapping changes. I'm mapping 2 channels to a 7.1 system and then one or both channel disappear or rather is mapped to another outputs. I've searched this thread for a possible solution but I haven't found anything. It could of course be in Alsa as well (since that is what i am using). Haven't found anything useful in camilladsp logs. Any help would be appreciated.
Do you want to run version 1.0? If yes there is no need to compile, just download the binary from the Releases page on GitHub.
If you do need to compile, then you need to download the complete sources, either with git or as a zip from GitHub. Then run the cargo command in the directory where you placed the source files (where the Cargo.toml file should be).
@Nisse10000 I haven't heard of this problem before. Can you try with something else than Camilladsp? The "aplay" tool would be ideal. You could prepare an 8-channel wav file with sound in the two channels you use with Audacity or such.
Does "then" mean "while playing goes on" or "when a new playback starts"?
Yes, that makes sense. Will do, have to figure out a good way since it may take quite a while before it happens.
It happens during playback. It happens faster when I use usb input from my TV, then it usually happens within 30 min. With LMS only it can be hours. Have tried with Plexamp as well which acts similarly to usb input. Which leads me to believe that it has something with load to do.
Last edited:
Hi,
I am new to this subforum and also quite outdated in S/W knowledge. So, I'd like to ask a very newbie lazy question at high-level.
I am looking at putting together a S/W-based HT system based on M1 Mac mini, a UHD BD drive and 16+ channel USB DAC. One key component I want to use is Dirac plug-in. So, there will be one of S/W BD player, Audirvana, VLC, Apple Music, Apple TV+ being the source, then hopefully they will be able to use the Dirac plug-in to apply the room correction filtering. Then CamillaDSP is taking the player output for my own FIR crossover. Finally CamillaDSP does, preferably, split, FIR filtering, delay, summation and gain to create final outputs to DAC channels.
I'd like to first ask if this system and signal flow is feasible. Please start with confirmation or explanation why it can't be. Thank you very much in advance.
Regards,
Jay
I am new to this subforum and also quite outdated in S/W knowledge. So, I'd like to ask a very newbie lazy question at high-level.
I am looking at putting together a S/W-based HT system based on M1 Mac mini, a UHD BD drive and 16+ channel USB DAC. One key component I want to use is Dirac plug-in. So, there will be one of S/W BD player, Audirvana, VLC, Apple Music, Apple TV+ being the source, then hopefully they will be able to use the Dirac plug-in to apply the room correction filtering. Then CamillaDSP is taking the player output for my own FIR crossover. Finally CamillaDSP does, preferably, split, FIR filtering, delay, summation and gain to create final outputs to DAC channels.
I'd like to first ask if this system and signal flow is feasible. Please start with confirmation or explanation why it can't be. Thank you very much in advance.
Regards,
Jay
@jheoaustin I see no reason why this would not work. CamillaDSP can do all the splitting/filtering/summing you mention.
I have no experience with Dirac. IIUC then it presents a virtual soundcard that you use as output device. It outputs the processed sound to another device of your choice. If you let it output to Blackhole and let CamillaDSP capture from that it should work. Don't know what latency to expect though since it's a fairly long chain.
I have no experience with Dirac. IIUC then it presents a virtual soundcard that you use as output device. It outputs the processed sound to another device of your choice. If you let it output to Blackhole and let CamillaDSP capture from that it should work. Don't know what latency to expect though since it's a fairly long chain.