x3
Lots of options outside of the RPi.
I really like the 2012 Mac mini for CamillaDSP applications as well. Has TOSLINK output and a FireWire port which opens the door to a lot of decent but cheap pro audio interfaces. I use mine with a RME Fireface 800 and it does great, on the -10 dBV output setting it has lower noise than my Okto dac8 pro and was a third of the price.
Michael
Last edited:
Thanks for making this great software!
I've stumble on a strange behaviour for the capture device Most often after a reboot I have to alternate the Loopback Device #0 or #1 in CamillaDSP config.yml and squeezelite conf to get sound. With no luck I've tried to find a way to check if any other program grab the Loopback device before Cdsp at boot.
To clarify, when error occur I alter the capture device: "hw:Loopback,1,0". And next time back to device: "hw:Loopback,0,0" with matching changes made to squeezelite's conf.
RPi3 with fresh installed 64b Raspberry-OS Lite with full-upgrade.
Error message:
I've stumble on a strange behaviour for the capture device Most often after a reboot I have to alternate the Loopback Device #0 or #1 in CamillaDSP config.yml and squeezelite conf to get sound. With no luck I've tried to find a way to check if any other program grab the Loopback device before Cdsp at boot.
To clarify, when error occur I alter the capture device: "hw:Loopback,1,0". And next time back to device: "hw:Loopback,0,0" with matching changes made to squeezelite's conf.
RPi3 with fresh installed 64b Raspberry-OS Lite with full-upgrade.
Error message:
Code:
---
devices:
samplerate: 44100
chunksize: 2048
capture:
type: Alsa
channels: 2
device: "hw:Loopback,0,0"
format: S16LE
playback:
type: Alsa
channels: 2
device: "hw:Headphones,0,0"
format: S16LE
Thanks! Installed lsof. Anything standing out here?
I guess C=Card, D=Device but what are the last letters p, c and none ?
Working system after manually reconfigured:
Code:
sudo lsof /dev/snd/*
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
camillads 1386 root 5u CHR 116,0 0t0 172 /dev/snd/controlC0
camillads 1386 root 6u CHR 116,48 0t0 217 /dev/snd/pcmC1D0p
camillads 1386 root 7u CHR 116,24 0t0 169 /dev/snd/pcmC0D0c
squeezeli 1437 root mem CHR 116,17 170 /dev/snd/pcmC0D1p
squeezeli 1437 root 4u CHR 116,17 0t0 170 /dev/snd/pcmC0D1p
Code:
sudo lsof /dev/snd/*
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
squeezeli 625 root mem CHR 116,17 170 /dev/snd/pcmC0D1p
squeezeli 625 root 4u CHR 116,17 0t0 170 /dev/snd/pcmC0D1p
Code:
SL_SOUNDCARD=hw:CARD=Loopback,DEV=1
I also don't run on a pi except for testing. My main system is a 7 year old mini-itx system with a dual core pentium (Skylake) CPU, in a case that is just slightly larger than the board itself. I'm very happy with it, it just works. I considered a getting a nuc. That would have been a little smaller, but at the time they were more expensive than building from components.
The system is also used for tv and movies, where it has no issues playing back any kind of hd content.
The system is also used for tv and movies, where it has no issues playing back any kind of hd content.
p/c = playback/capture
Did squeezelite open the loopback at 44100/2/16 when CDSP could not open the other side with these hw params?
Code:
cat /proc/asound/card0/pcm1p/sub0/hw_paramsThanks @phofman. I think I've confirmed your suspicion.
If I restart the CDSP daemon it fail with the same error. But if I first stop the Squeezelite daemon then restart CDSP it will start.
But still no sound when I start SL. Implying there is incompatible with my c/p config where ALSA as I understand it will run the card with settings from the application first opening the card independed if it is capture or play device.
But why does it work when I alter config files? I've noticed CDSP usually trigger and use new settings when I save the config file.
Canges to SL I have to restart the daemon.
@HenrikEnquist 🙂 RPi can by the look at of support requests seam like at troublesome device. But I think this stems more from the large number of devices flooded the marked to linux nobs like me. I like the power they provide at low cost throughout their lifespan. Without any sleep configuration yearly power consumption at 24/7 are around 0.8 KW for the RPi3.
If I restart the CDSP daemon it fail with the same error. But if I first stop the Squeezelite daemon then restart CDSP it will start.
But still no sound when I start SL. Implying there is incompatible with my c/p config where ALSA as I understand it will run the card with settings from the application first opening the card independed if it is capture or play device.
But why does it work when I alter config files? I've noticed CDSP usually trigger and use new settings when I save the config file.
Canges to SL I have to restart the daemon.
I changed the capture device to reflect player format S32_LE. But no luck at next reboot.
@HenrikEnquist 🙂 RPi can by the look at of support requests seam like at troublesome device. But I think this stems more from the large number of devices flooded the marked to linux nobs like me. I like the power they provide at low cost throughout their lifespan. Without any sleep configuration yearly power consumption at 24/7 are around 0.8 KW for the RPi3.
Not really closer to an understanding what's going on, but the following workaround makes sound.
It seems I've tricked myself. It's not the editing of the file, but the initializing of the daemons and the order they start. Whom grab the Loopback card first. Even though it seem they are opening with identical parameters except buffer size.
This would be an easy fix if Squeezelite where started from systemctl and not initd as it is. Where we could tell squeezelite.service to wait for CDSP. I had a go at having init.d start SL last to no avail:
I'll look into making a service startup file for Squeezelite. Have to figure out how to import the config file, rest is copy paste from CDSP I guess.
Bash:
sudo systemctl stop squeezelite
sudo systemctl restart camilladsp
sudo systemctl start squeezeliteIt seems I've tricked myself. It's not the editing of the file, but the initializing of the daemons and the order they start. Whom grab the Loopback card first. Even though it seem they are opening with identical parameters except buffer size.
This would be an easy fix if Squeezelite where started from systemctl and not initd as it is. Where we could tell squeezelite.service to wait for CDSP. I had a go at having init.d start SL last to no avail:
sudo update-rc.d squeezelite defaults 99I'll look into making a service startup file for Squeezelite. Have to figure out how to import the config file, rest is copy paste from CDSP I guess.
I use squeezelite with CDSP without issue but I wonder if it is because I run it with "-C 5" so that it closes the output device after 5 seconds of inactivity. Might be an easy fix to your issues.
Michael
Michael
I first typed the long story but realized none is interested and just skipped to the ending 😉
As it turns out 'camilladsp.service' never ran at boot even though it was Enabled and worked fine from the console. Combined with an early error in the device setting confirmed by starting CDSP manually confused me.
This is the service file I'm been working with:
https://github.com/HEnquist/camilladsp-config/blob/master/camilladsp.service
There are two errors in this service file for my use on Debian like OS. What stopped it from running at boot on my non graphical system where this line:
systemctl get-default will return what target to use
Now when the service actually run systemd complain about the syslog entries
As it turns out 'camilladsp.service' never ran at boot even though it was Enabled and worked fine from the console. Combined with an early error in the device setting confirmed by starting CDSP manually confused me.
This is the service file I'm been working with:
https://github.com/HEnquist/camilladsp-config/blob/master/camilladsp.service
There are two errors in this service file for my use on Debian like OS. What stopped it from running at boot on my non graphical system where this line:
Code:
[Install]
# original setting
WantedBy=graphical.target
# this one worked for me
WantedBy=multi-user.targetsystemctl get-default will return what target to use
Code:
pi@RPi:~ $ systemctl get-default
multi-user.targetNow when the service actually run systemd complain about the syslog entries
to silence this warning:
Code:
StandardOutput=journal
StandardError=journalLoopback device allows to be opened with identical rate/channel count/format on both sides only. The reason is it does nothing to the samples, it just copies the blocks of memory between input and output buffers (or maybe just shares one memory segment between both sides and plays just with pointers, I have not studied the code).
CDSP always uses the format you request. But many players try to use their default params, but adjust them, if the output device does not support the default. It's possible squeezelite does that. That would explain why the order CDSP -> squeezelite works (SL adjusts its format to fit the loopback) but SL -> CDSP not (CDSP allows no adjustment).
IMO you should fully specify fixed output format for SL, like it's in CDSP. Should it not be possible, you can configure a PCM device for the Loopback card in asound config with fixed rate + channels + format identical to CDSP, and use that one in SL.
Buffer size is individual for each side, no problem with that.
Let's say 1.5W http://www.pidramble.com/wiki/benchmarks/power-consumption * 1/0.8 for some decent power adapter * 24 hours * 365 days => 16kWh per year. Tiny, no doubts.
Numbers where calculatet from readouts of a USB mW/h meter running over several days on a RPi3, then adding 20% power loss. Maybe manually calculation come up with something else?
Typical idle current with the same meter are 154mA with peaks double that. Same meter now show 220mA playing Squeezelite/CDSP 5 tap EQ where a sigle core run at 53% load with CPU speed 1200MHz. Normally CPU idle at 600 MHz and will play Squeezelite at this speed where it only speed up at track changes before setteling down again.
If we simplify and use idle current for 25 hours
(154mA *5.1V /1000) *25h *365d *1.2 /1000 ≈ 8,6 kWh/Y
Thanks guys for clarifying! Now I have to figure out if I misplaced a decimal or my meter W/h calc are off. Probably the former 😉
Typical idle current with the same meter are 154mA with peaks double that. Same meter now show 220mA playing Squeezelite/CDSP 5 tap EQ where a sigle core run at 53% load with CPU speed 1200MHz. Normally CPU idle at 600 MHz and will play Squeezelite at this speed where it only speed up at track changes before setteling down again.
If we simplify and use idle current for 25 hours
(154mA *5.1V /1000) *25h *365d *1.2 /1000 ≈ 8,6 kWh/Y
Thanks guys for clarifying! Now I have to figure out if I misplaced a decimal or my meter W/h calc are off. Probably the former 😉
Not to familiar with GitHub. Are there option to have static links - ie. som kind of symbolic links to lateset binaries and install packages? Rather than refering to actual revision number GitHub always point to latest file?
I'm trying to create an install script for RPi-OS that have Squeezelite and CDSP with GUI up and running with the headphone output for users to have a quick way to demo this great program. But fear I will have problem keep script up to date with Henriks development speed.
Bash:
'pip3 install git+https://github.com/HEnquist/pycamilladsp-plot.git@v1.0.2'
'pip3 install git+https://github.com/HEnquist/pycamilladsp-plot.git@latest'I'm trying to create an install script for RPi-OS that have Squeezelite and CDSP with GUI up and running with the headphone output for users to have a quick way to demo this great program. But fear I will have problem keep script up to date with Henriks development speed.
Last edited:
You can link to the latest release, but that will surely lead to problems. I don't release the new versions of all parts at the same time. I usually start with camilladsp itself, followed by pycamilladsp. Then I start on pycamilladsp-plot and the GUI. If you the pull the latest of everything after the camilladsp release but before the gui release, you would then end up with mismatched versions.
Thanks! Sadly that would make an install or update script rather convelutet as it would need to test every package link before making desisssion. Then probe hyperlinks to test if matches exist. Worst case we have to parse md files for clues.
Would it be possible on the main directory have a page named something like 'currentstableversion.md'. Only contaning the revision number where all the bits and pieces fit? You already have a consistent naming scheme so comming install and update scripts would then be easy to adapt for web gui etc. used in many distros.
When this is written most current files not to be considered compatible?
Bash:
wget https://github.com/HEnquist/camilladsp/releases/download/v1.0.2/camilladsp-linux-aarch64.tar.gz -P ~/camilladsp/
pip3 install git+https://github.com/HEnquist/pycamilladsp.git@v1.0.0
pip3 install git+https://github.com/HEnquist/pycamilladsp-plot.git@v1.0.2
wget https://github.com/HEnquist/camillagui-backend/releases/download/v1.0.0/camillagui.zip -P ~/camilladsp/