The RPi is quite a bit slower, so the timing during the camilladsp start-up may also be quite different. That may be sufficient to avoid the issue. Could you show the log from a start on the pi?
2022-07-22 15:52:38.730557 INFO [src/bin.rs:712] CamillaDSP version 1.0.0
2022-07-22 15:52:38.730734 INFO [src/bin.rs:713] Running on linux, aarch64
2022-07-22 15:52:38.730874 DEBUG [src/bin.rs:755] Read config file Some("/home/michael3/camilladsp/active_config.yml")
2022-07-22 15:52:38.732083 DEBUG [src/bin.rs:774] Config is valid
2022-07-22 15:52:38.732255 DEBUG [src/socketserver.rs:260] Start websocket server on 127.0.0.1:1234
2022-07-22 15:52:38.732555 DEBUG [src/bin.rs:858] Wait for config
2022-07-22 15:52:38.732651 DEBUG [src/bin.rs:891] Config ready
2022-07-22 15:52:38.733102 DEBUG [src/filters.rs:465] Build new pipeline
2022-07-22 15:52:38.733103 DEBUG [src/bin.rs:214] Using channels [true, true, false, false]
2022-07-22 15:52:38.733296 DEBUG [src/filters.rs:366] Build from config
2022-07-22 15:52:38.733409 DEBUG [src/filters.rs:366] Build from config
2022-07-22 15:52:38.733500 DEBUG [src/filters.rs:366] Build from config
2022-07-22 15:52:38.733585 DEBUG [src/filters.rs:366] Build from config
2022-07-22 15:52:38.733686 DEBUG [src/processing.rs:19] build filters, waiting to start processing loop
2022-07-22 15:52:38.736365 DEBUG [src/alsadevice.rs:324] Capture: supported channels, min: 4, max: 4, list: [4]
2022-07-22 15:52:38.736365 DEBUG [src/alsadevice.rs:324] Playback: supported channels, min: 4, max: 4, list: [4]
2022-07-22 15:52:38.736484 DEBUG [src/alsadevice.rs:325] Capture: setting channels to 4
2022-07-22 15:52:38.736508 DEBUG [src/alsadevice.rs:325] Playback: setting channels to 4
2022-07-22 15:52:38.736665 DEBUG [src/alsadevice.rs:329] Capture: supported samplerates: Discrete([44100, 48000, 88200, 96000, 176400, 192000])
2022-07-22 15:52:38.736676 DEBUG [src/alsadevice.rs:329] Playback: supported samplerates: Discrete([44100, 48000, 88200, 96000, 176400, 192000])
2022-07-22 15:52:38.736753 DEBUG [src/alsadevice.rs:330] Capture: setting rate to 96000
2022-07-22 15:52:38.736766 DEBUG [src/alsadevice.rs:330] Playback: setting rate to 96000
2022-07-22 15:52:38.736857 DEBUG [src/alsadevice.rs:334] Capture: supported sample formats: [S32LE]
2022-07-22 15:52:38.736863 DEBUG [src/alsadevice.rs:334] Playback: supported sample formats: [S32LE]
2022-07-22 15:52:38.736937 DEBUG [src/alsadevice.rs:335] Capture: setting format to S32LE
2022-07-22 15:52:38.736941 DEBUG [src/alsadevice.rs:335] Playback: setting format to S32LE
2022-07-22 15:52:38.739672 DEBUG [src/alsadevice.rs:359] Opening audio device "hw:M4" with parameters: HwParams { channels: Ok(4), rate: "Ok(96000) Hz", format: Ok(S32LE), access: Ok(RWInterleaved), period_size: "Ok(512) frames", buffer_size: "Ok(4096) frames" }, SwParams(avail_min: Ok(2048) frames, start_threshold: Ok(0) frames, stop_threshold: Ok(4096) frames)
2022-07-22 15:52:38.739798 DEBUG [src/alsadevice.rs:359] Opening audio device "hw:M4" with parameters: HwParams { channels: Ok(4), rate: "Ok(96000) Hz", format: Ok(S32LE), access: Ok(RWInterleaved), period_size: "Ok(512) frames", buffer_size: "Ok(4096) frames" }, SwParams(avail_min: Ok(2048) frames, start_threshold: Ok(1) frames, stop_threshold: Ok(4096) frames)
2022-07-22 15:52:38.739822 DEBUG [src/alsadevice.rs:364] Audio device "hw:M4" successfully opened
2022-07-22 15:52:38.739914 DEBUG [src/alsadevice.rs:364] Audio device "hw:M4" successfully opened
2022-07-22 15:52:38.739964 DEBUG [src/bin.rs:334] Capture thread ready to start
2022-07-22 15:52:38.740047 DEBUG [src/bin.rs:324] Playback thread ready to start
2022-07-22 15:52:38.740131 DEBUG [src/bin.rs:327] Both capture and playback ready, release barrier
2022-07-22 15:52:38.740278 DEBUG [src/bin.rs:329] Supervisor loop starts now!
2022-07-22 15:52:38.740282 DEBUG [src/alsadevice.rs:979] Starting captureloop
2022-07-22 15:52:38.740308 DEBUG [src/processing.rs:21] Processing loop starts now!
2022-07-22 15:52:38.740348 DEBUG [src/alsadevice.rs:888] Starting playback loop
2022-07-22 15:52:38.740434 DEBUG [src/alsadevice.rs:384] Playback loop uses a buffer of 2048 frames
2022-07-22 15:52:38.740623 DEBUG [src/alsadevice.rs:608] Capture loop uses a buffer of 4096 frames
2022-07-22 15:52:38.740866 DEBUG [src/alsadevice.rs:235] Starting capture from state: SND_PCM_STATE_PREPARED, Ready to start
2022-07-22 15:52:38.763716 INFO [src/alsadevice.rs:136] PB: Starting playback from Prepared state
$ head /proc/asound/card2/stream0
MOTU M4 at usb-0000:01:00.0-1.3, high speed : USB Audio
Playback:
Status: Stop
Interface 1
...
silence_timeout
parameters determines how long after sound stops the Running status persists before changing to Stop.silence_timeout
to 10 minues seems reasonable in my case to turn off amp after stops playing. Yeah, post it up. I've been thinking about exploring the same except sending the gpio to the internal trigger of the Ncore.I recently got a Hypex amp from VTV. The amp is very basic and it only has an on/off AC switch in the back. After quick exchange with VTV folks they mentioned that most people are using external AC outlets to control the power to their amps.
So, that got me thinking on how I can do this with the stuff I have around? For home automation I use "Kasa Smart Wi-Fi Plug Mini" switches. So I can connect the amp to that. Only thing left would be to be able to control it from the Raspberry Pi running CamillaDSP.
After some invetigation I noticed that in my setup the following file has a nice indication when Camilla payback is happening by looking at the Playback/Status parameter which has values of Stop when silent and Running when playing music:
Code:$ head /proc/asound/card2/stream0 MOTU M4 at usb-0000:01:00.0-1.3, high speed : USB Audio Playback: Status: Stop Interface 1 ...
The Camillasilence_timeout
parameters determines how long after sound stops the Running status persists before changing to Stop.
So only thing left is how to control the Smart Plug from the Pi? For that there is a very nice library https://github.com/python-kasa/python-kasa which does the trick.
Armed with these tools, I wrote a little python script which monitors the state of the playback stream and turns the amp on and off when appropiate. Settingsilence_timeout
to 10 minues seems reasonable in my case to turn off amp after stops playing.
Let me know if there is interest on this code, and I can clean up and publish to a public git repo.
getAmpState
and setAmpState
to use GPIO instead of calling python-kasa
]python-kasa[/ICODE]
I recently got a Hypex amp from VTV. The amp is very basic and it only has an on/off AC switch in the back. After quick exchange with VTV folks they mentioned that most people are using external AC outlets to control the power to their amps.
So, that got me thinking on how I can do this with the stuff I have around? For home automation I use "Kasa Smart Wi-Fi Plug Mini" switches. So I can connect the amp to that. Only thing left would be to be able to control it from the Raspberry Pi running CamillaDSP.
After some invetigation I noticed that in my setup the following file has a nice indication when Camilla payback is happening by looking at the Playback/Status parameter which has values of Stop when silent and Running when playing music:
Code:$ head /proc/asound/card2/stream0 MOTU M4 at usb-0000:01:00.0-1.3, high speed : USB Audio Playback: Status: Stop Interface 1 ...
The Camillasilence_timeout
parameters determines how long after sound stops the Running status persists before changing to Stop.
So only thing left is how to control the Smart Plug from the Pi? For that there is a very nice library https://github.com/python-kasa/python-kasa which does the trick.
Armed with these tools, I wrote a little python script which monitors the state of the playback stream and turns the amp on and off when appropiate. Settingsilence_timeout
to 10 minues seems reasonable in my case to turn off amp after stops playing.
Let me know if there is interest on this code, and I can clean up and publish to a public git repo.
Should be simple to change the code to control two plugs, not just one.-Can it work with 2 plugs? I have 2x monoblocks.
The general idea is to control the state of the amp based on the playback state. In camillaDSP, the playback state switches from Running to Paused after the configurable-Will the amps stay on when in a "Paused" state? Would be good if they did, imo.
silence_timeout
value, so you can choose to make the number as large as you like. For example: turn off amp 1 hour after camillaDSP stopped playing music. Not sure I understand this question. The script relies on the playback channel state associated with camillaDSP, not the capture channel so it should be source independent.-What happens when sources are switched?
Should be simple to change the code to control two plugs, not just one.
The general idea is to control the state of the amp based on the playback state. In camillaDSP, the playback state switches from Running to Paused after the configurablesilence_timeout
value, so you can choose to make the number as large as you like. For example: turn off amp 1 hour after camillaDSP stopped playing music.
Alternatively, it would be simple to turn the amp on when the state changes from Paused to Running and nothing else. This would leave it up to you to turn off the amp manually (like asking Alexa) or some other automation in the Kasa app like "turn amps off at 1 AM" in case you forgot.
Not sure I understand this question. The script relies on the playback channel state associated with camillaDSP, not the capture channel so it should be source independent.
That's correct. Look at the playback loop https://github.com/HEnquist/camilla...c0230f15741a445b07cc62/src/alsadevice.rs#L480 :Also, when playback is "Paused" in CamillaDSP, the device is still "Running" when I use:
head /proc/asound/card1/stream0