• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

RPi4 + CamillaDSP Tutorial

phofman

Senior Member
Joined
Apr 13, 2021
Messages
489
Likes
319
Testing would certainly require building a new kernel with the respective patch from the devs. There were many changes in the USB-audio driver recently, IMO the latest kernel would be required. Just guessing from my previous experience
 
OP
M

mdsimon2

Major Contributor
Forum Donor
Joined
Oct 20, 2020
Messages
2,478
Likes
3,316
Location
Detroit, MI
Your comments about USB driver updates made me wonder if I would see the same issues on my Raspberry Pi OS / 5.18 setup.

Tried both the M4 and Ultralite Mk5 and they were fine without resampling. Of course there are a lot of different variables here (different OS, different kernel) but maybe the issue has already been solved in newer kernels?

Michael
 

phofman

Senior Member
Joined
Apr 13, 2021
Messages
489
Likes
319
Could be, these reports usually require testing on the latest kernel first.
 

HenrikEnquist

Member
Joined
Jul 1, 2021
Messages
82
Likes
110
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?
 
OP
M

mdsimon2

Major Contributor
Forum Donor
Joined
Oct 20, 2020
Messages
2,478
Likes
3,316
Location
Detroit, MI
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?

They are both RPi4s but different operating systems, I had issues with Ubuntu 22.04 (5.15) but did not have issues with Raspberry Pi OS 11 (5.18).

Here is the log from Raspberry Pi OS with the M4 on CamillaDSP V1.0.0.

Code:
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

Michael
 

igfarm

Member
Joined
Jan 16, 2021
Messages
36
Likes
28
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 Camilla silence_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. Setting silence_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.
 

chuckt62

Active Member
Editor
Joined
Apr 6, 2022
Messages
141
Likes
123
Location
Tejas
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 Camilla silence_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. Setting silence_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.
Yeah, post it up. I've been thinking about exploring the same except sending the gpio to the internal trigger of the Ncore.
 

bambadoo

Member
Joined
Jan 12, 2017
Messages
67
Likes
96
Nice writeup.
Using icepower 1200as2 amps myself. Auto-off without signal is implemented which is a great feature. However it is "hardcoded" on the modules itself to turn off after 13minutes without signal.
 

MCH

Major Contributor
Joined
Apr 10, 2021
Messages
2,581
Likes
2,199
Thanks @igfarm , that is a terrific feature. From their website it seems that these kasa plugs exist only in US version. Is anyone aware of an european version or equivalent?

Edit: maybe "Tapo"? (Kasa < tp-link > tapo??)
https://amzn.eu/d/9qU7C0Y
 

somebodyelse

Major Contributor
Joined
Dec 5, 2018
Messages
3,684
Likes
2,963
There are loads of broadly equivalent switches that can be controlled either directly, or indirectly bridged via home control systems or other gateways. ZigBee is reasonably well standardized and supported by major manufacturers, although they aren't always clear that's what they're using like Ikea's Tradfri or Philips' Hue products.
https://www.zigbee2mqtt.io/supported-devices/
WiFi ones are more likely to use proprietary control protocols, but a fair number can have their firmware replaced with an open alternative:
https://tasmota.github.io/docs/Configuration-Procedure-for-New-Devices/
 

MCH

Major Contributor
Joined
Apr 10, 2021
Messages
2,581
Likes
2,199
I see, thanks.
I was wondering if the tapo branded ones would also work following @igfarm instructions (that make use of the python-kasa library) straight away for noobs like me that rapidly get lost with these things :D
In the meantime i learned that tapo is the new brand of tp-link for these also in the US. But they seem to be slightly different.
 

jdubs

Member
Forum Donor
Joined
Mar 12, 2018
Messages
97
Likes
19
]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 Camilla silence_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. Setting silence_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.

Thanks for doing this! A few questions:

-Can it work with 2 plugs? I have 2x monoblocks.
-Will the amps stay on when in a "Paused" state? Would be good if they did, imo.
-What happens when sources are switched?

Thanks!
Jim
 

igfarm

Member
Joined
Jan 16, 2021
Messages
36
Likes
28
-Can it work with 2 plugs? I have 2x monoblocks.
Should be simple to change the code to control two plugs, not just one.

-Will the amps stay on when in a "Paused" state? Would be good if they did, imo.
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 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.

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.

-What happens when sources are switched?
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.
 

jdubs

Member
Forum Donor
Joined
Mar 12, 2018
Messages
97
Likes
19
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 configurable 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.

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.

Thanks! Was just curious about if changing the source would affect the playback state in a way that wouldn't be compatible with this. I'm good at understanding it now.

A question: What would be the coding change to include 2 devices?

Also, when playback is "Paused" in CamillaDSP, the device is still "Running" when I use:

head /proc/asound/card1/stream0

-Jim
 
Last edited:

phofman

Senior Member
Joined
Apr 13, 2021
Messages
489
Likes
319
Also, when playback is "Paused" in CamillaDSP, the device is still "Running" when I use:

head /proc/asound/card1/stream0
That's correct. Look at the playback loop https://github.com/HEnquist/camilla...c0230f15741a445b07cc62/src/alsadevice.rs#L480 :

The playback thread has the playback device open (i.e. "Running" in stream0), and it's reading/waiting for messages sent from the processing thread. The messages are either AudioMessage::Audio with audio data https://github.com/HEnquist/camilla...c0230f15741a445b07cc62/src/alsadevice.rs#L482, or a control message, e.g. AudioMessage::pause https://github.com/HEnquist/camilla...c0230f15741a445b07cc62/src/alsadevice.rs#L538 . As you see, the pause message does nothing, no data written to the playback device, and the thread continues the loop with waiting for another message from Processing.

Therefore the Pause does nothing to the output device, keeping it open ("Running")

Just a note - if you check contents of file /proc/asound/cardX/pcmYp/subZ/hw_params for presence of "closed" in the first line, your code will work for all output sound devices, not only for USB soundcards.
 

Eternalight

Member
Joined
Jul 31, 2022
Messages
11
Likes
0
I have an audioinjector Octo8. It works. When I tried to set up camilladsp, now I don't get sound. I don't understand the routing. I need code in asound.conf for Octo8 to work and other code to make camilladsp work. How do I combine the code? As of now, it looks like they both are trying to be the default.

P.S. Ignore the lack of filters, pipeline, mixer in alsaconfig.yml. I had it all in there but somehow it got deleted 5 mins ago. I was rushing, 30 min edit time lol

Sincerely,
David Piel
 

Attachments

  • 2022-07-31.png
    2022-07-31.png
    2.1 MB · Views: 55
  • asound.zip
    1.3 KB · Views: 52
Last edited:
Top Bottom