-
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!
RPi + CamillaDSP Tutorial
- Thread starter mdsimon2
- Start date
terryforsythe
Major Contributor
Thank you!
I just installed GUI version 3.0.1, I think. The GUI indicates "CamillaGUI version 3.0.0"
- Thread Starter
- #2,343
Thank you!
I just installed GUI version 3.0.1, I think. The GUI indicates "CamillaGUI version 3.0.0"
Yes, to be fixed in 3.0.2 -> https://www.diyaudio.com/community/...overs-room-correction-etc.349818/post-7929280
Michael
somebodyelse
Major Contributor
- Joined
- Dec 5, 2018
- Messages
- 4,983
- Likes
- 4,506
Which 'it' are you referring to here? The MCHstreamer, or alsamixer? In most distros it's configurable whether to apply a saved mixer state at startup, or save a state at shutdown. You could also script the state changes to set clock source to internal, start CamillaDSP, maybe pause, then set clock source to TOSLINK.
What part of MCHstreamer stops working when the main clock is not coming from the SPDIF input? Does it freeze completely (incl. USB) or does it stop providing/consuming samples but the USB features are still available (e.g. the clock source feature)?
- Thread Starter
- #2,346
I guess to me they are the same, the MCHstreamer has no software on linux, but alsamixer reports the same clock source setting.
How is this typically controlled?
Yes, you could definitely go this route (I mentioned it in an early post to @MDG).
Important to note the issue is if the MCHstreamer clock source is set to TOSLINK then CamillaDSP will not start. When the clock source is set to internal everything works fine. If CamillaDSP is already running, then it is possible to switch between internal and TOSLINK clock source without issue.
Here is another oddity, if there is physically no TOSLINK source (TOSLINK input cable is unplugged) and alsamixer clock source is set to TOSLINK and CamillaDSP is restarted (either by restarting the service or rebooting the RPi), the clock source will switch to internal in alsamixer and CamillaDSP will start without issue.
When CamillaDSP does not work it actually stays in the running state but level meters do not move at all. All other USB functions seem to work, I can change the clock in alsamixer.
I've attached a debug level log from attempting to start CamillaDSP with the clock source set to TOSLINK.
Michael
What a mess from the UI components trace logs, unrelated to the issue. If I may suggest, please untill this commit https://github.com/HEnquist/camilladsp/commit/623c574cfdd15df7475e444c2c67205c3c15c57a is included in the binaries, to run CDSP from command line without the UI balast for the log-analysis purposes? I think this config will need to find way to the UI configuration too, to avoid the clutter.
After filtering only alsa lines from the log, to see what is actually going on - the playback device never accepts any data. It's a standard behaviour of devices clocked by SPDIF receiver which the vendor designed cheaply and avoided the important "freewheeling" crystal. Good SPDIF receiver chips support an auxiliary crystal which kicks in when no SPDIF signal is present, keeping the master clock the receiver generates freewheeling and the chain working. PCI soundcards with Envy24 without that crystal (e.g. Audiotrak Prodigy with SPDIF IO addon) would not even respond to amixer commands at this situation (fortunately the USB layer seems to be working here), unable to be switched back from external to internal clocks. Well-designed cards (e.g. ESI Juli@) had the crystal connected to their AKM SPDIF receiver and did not get stuck. As a bonus these cards could report incoming SPDIF rate correctly (because the SPDIF receiver had a reference clock to measure the incoming rate against).
From the manpage of alsactl:
Code:
...
store <card>
This command saves the current driver state for the selected soundcard to the configuration file.
restore <card>
This command loads driver state for the selected soundcard from the configuration file. If restoring fails (eventually partly), the init action is called.
...
-f, --file
Select the configuration file to use. The default is /var/lib/alsa/asound.state.
-a, --config-dir
Select the boot / hotplug ALSA configuration directory to use. The default is /var/lib/alsa.
...In distros using systemd, which is most these days, this is managed by the service
alsa-restore.service.@mdsimon2 : You are doing a great job, my rant was towards miniDSP for this trap.
There is not much CDSP can do when the device does not consume samples.Theoretically it could flip to paused and rely on some external controller to unpause, after the problem resolves.
Does amixer offer some "clock valid" control for the MCHstreamer? Checking for the clock validity is part of UAC2, chapter 5.2.5.1.2 describes clock validity control, and linux UAC2 driver should report it via Clock Source XXX Validity ctl https://github.com/torvalds/linux/b...c394d046ce64fe1/sound/usb/mixer.c#L1968-L1977 . This ctl could be used in some wrapper around CDSP.
There is not much CDSP can do when the device does not consume samples.Theoretically it could flip to paused and rely on some external controller to unpause, after the problem resolves.
Does amixer offer some "clock valid" control for the MCHstreamer? Checking for the clock validity is part of UAC2, chapter 5.2.5.1.2 describes clock validity control, and linux UAC2 driver should report it via Clock Source XXX Validity ctl https://github.com/torvalds/linux/b...c394d046ce64fe1/sound/usb/mixer.c#L1968-L1977 . This ctl could be used in some wrapper around CDSP.
- Thread Starter
- #2,351
Yes, it has controls for TOSLINK and internal clock validity, it seems like internal clock validity always returns on. The TOSLINK clock validity acts as expected, returns off with no TOSLINK source and on with a TOSLINK source.
Michael
Code:
michael2@raspberrypi2:/proc/asound/TosLink $ amixer -D hw:TosLink cget numid=8
numid=8,iface=CARD,name='miniDSP TOSLINK Clock Validity'
; type=BOOLEAN,access=r-------,values=1
: values=on
michael2@raspberrypi2:/proc/asound/TosLink $ amixer -D hw:TosLink cget numid=8
numid=8,iface=CARD,name='miniDSP TOSLINK Clock Validity'
; type=BOOLEAN,access=r-------,values=1
: values=offMichael
Very good. Then a controller like https://github.com/marcoevang/camilladsp-setrate or easier in python https://github.com/HEnquist/camilladsp-controller could be modified to follow this control and pause/unpause CDSP like for the gadget/loopback.
terryforsythe
Major Contributor
- Thread Starter
- #2,354
Made an update to the tutorial that doubled the chunk sizes for physical input example configurations.
My previous values were a bit too low and I noticed occasional buffer under runs on my UL Mk5 system (~1 every hour) when testing out V3. At first I thought it was a V3 specific issue but after re-installing V2 I experienced the same issue. It was difficult to see because my log is full of start / stops, but they stand out when removing the silence timeout. My thinking on chunk sizes was also biased because the Okto can run with very lower chunk sizes without issue and that is the DAC in my main system.
Latency for physical input configurations is now around 15 ms, which is still very reasonable for A/V applications. New chunk sizes are summarized below.
44.1 / 48 kHz: 128
88.2 / 96 kHz: 256
176.4 / 192 kHz : 512
As always if you experience buffer under runs with these chunk sizes please let me know!
Michael
My previous values were a bit too low and I noticed occasional buffer under runs on my UL Mk5 system (~1 every hour) when testing out V3. At first I thought it was a V3 specific issue but after re-installing V2 I experienced the same issue. It was difficult to see because my log is full of start / stops, but they stand out when removing the silence timeout. My thinking on chunk sizes was also biased because the Okto can run with very lower chunk sizes without issue and that is the DAC in my main system.
Latency for physical input configurations is now around 15 ms, which is still very reasonable for A/V applications. New chunk sizes are summarized below.
44.1 / 48 kHz: 128
88.2 / 96 kHz: 256
176.4 / 192 kHz : 512
As always if you experience buffer under runs with these chunk sizes please let me know!
Michael
terryforsythe
Major Contributor
I am using USB Gadget capture. Using a 4096 chunksize and default (same as chunksize) target_level, I get buffer overruns the moment a 192k song comes on, but it clears relatively quickly - they all have the same time stamp - and does not affect the song playback.
I tried using a 1024 chunksize and 3072 target_level. It works with 192k, and I still get buffer overruns the moment the 192k song comes on, but with this configuration it takes a lot more clock cycles for the buffer overrun to clear judging by the sheer number of warning messages in my journal log. Still, they all have the same time stamp and the buffer overrun cleared before the song started playing.
In either case I don't notice any negative affects other than the log entries.
I tried using a 1024 chunksize and 3072 target_level. It works with 192k, and I still get buffer overruns the moment the 192k song comes on, but with this configuration it takes a lot more clock cycles for the buffer overrun to clear judging by the sheer number of warning messages in my journal log. Still, they all have the same time stamp and the buffer overrun cleared before the song started playing.
In either case I don't notice any negative affects other than the log entries.
Last edited:
Haven`t tried this, but most (new) devices from RME are class 2 compliant, so i could be done i think, but i would not be easy (for me).
What my intended use was to use camilladsp in a flexibel way parrellel to my own default route to analog out with a standard RME interface card. This standard interface card is connected to a window based system. So what i want to achieve is digital out (2ch) to a camilladsp station and Adat (8ch) back to my standaard RME interface card.
Thnx all for invastiging the issue`s with the MCH streamer, the posts are sharp as a tack!! As i understood correctly, the problem is the way the configuration of the clock (internal) is layed on the board of the MCH.
Are there any other simple cheap interface card with digital in and minimal Adat out?
Marcel
terryforsythe
Major Contributor
There is the S.M.S.L. PO100 Pro, which is $70 here in the U.S., but I don't know whether it outputs ADAT. It might be worth investigating.
PO100 Pro
Foshan ShuangMuSanLin electronics Co., LTD. founded in 2009 which located in Shenzhen, China. And our branch company VMV Technology(HK) Company Limited registered in HK in 2013. Our company is specialized in the audio DAC, stereo headphone amplifier, power amplifier, and with own R&D...
www.smsl-audio.com
somebodyelse
Major Contributor
- Joined
- Dec 5, 2018
- Messages
- 4,983
- Likes
- 4,506
Adding to @Honken's answer, it varies by distro. Look for an alsa or sound related init script in /etc/init.d or a systemd unit file under /etc/systemd/system. There may be config options too - places like /etc/default or /etc/conf.d most likely. Looking in the init script or unit file will tell you where it puts the state file.
Ubuntu 24.04 and derivatives still seem to use /etc/init.d/alsa-utils despite using systemd. It doesn't seem to have a config option to enable/disable save at stop, so you would have to edit the init script instead. If they haven't done it already in later versions, they'll soon have to migrate to a systemd unit.
Gentoo with openrc has /etc/conf.d/alsasound where you can set RESTORE_ON_START and SAVE_ON_STOP.
Hello,
Bravo
Thank you.
I've been following this thread since the beginning and thanks to the information provided I was able to replace a nanoDIGI to filter LXmini+2 speakers.
Up to cdsp v2 everything is OK.
Switching to cdsp v3 causes sound cuts, every 6 minutes, due to Alsa :
( WARN [src/alsadevice.rs:339] Capture: read overrun, trying to recover. Error: ALSA function 'snd_pcm_readi' failed with error 'Broken pipe (32)').
What error could have occurred?
The hardware and environment are identical, the installation is done from scratch by following the tutorial: https://github.com/mdsimon2/RPi-CamillaDSP.
I enclose the camilladsp.log and the beginning of my configuration file.
Any suggestions are welcome.
Bravo
Thank you.
I've been following this thread since the beginning and thanks to the information provided I was able to replace a nanoDIGI to filter LXmini+2 speakers.
Up to cdsp v2 everything is OK.
Switching to cdsp v3 causes sound cuts, every 6 minutes, due to Alsa :
( WARN [src/alsadevice.rs:339] Capture: read overrun, trying to recover. Error: ALSA function 'snd_pcm_readi' failed with error 'Broken pipe (32)').
What error could have occurred?
The hardware and environment are identical, the installation is done from scratch by following the tutorial: https://github.com/mdsimon2/RPi-CamillaDSP.
I enclose the camilladsp.log and the beginning of my configuration file.
Any suggestions are welcome.
- Thread Starter
- #2,360
Which RPi are you using?
You are using a pretty big target level (4 x chunk size), which would not have been possible with V2 which had a max target level of 2 x chunk size - 1. I'd try reverting back to your V2 target level and see if that solves it.
If it doesn't I'd try moving to 2048 chunk size / 6144 target level. I don't have a DM7 so I can't directly test your configuration but I can try a similar ALSA loopback configuration at 192 kHz and see how it does.
Michael
You are using a pretty big target level (4 x chunk size), which would not have been possible with V2 which had a max target level of 2 x chunk size - 1. I'd try reverting back to your V2 target level and see if that solves it.
If it doesn't I'd try moving to 2048 chunk size / 6144 target level. I don't have a DM7 so I can't directly test your configuration but I can try a similar ALSA loopback configuration at 192 kHz and see how it does.
Michael
