I have configured camillaDSP to start automatically as a service on my rPi4 (bookworm) but it always fails to open the HDMI playback device on startup.
Looking at the logs this seems to be because the ALSA hdmi playback device it is not (yet) available. If I restart the service manually after the boot it then always succeeds.
Unsuccessful service start at boot:
Is there a way to make the camillaDSP service start conditional on the ALSA HDMI device enumeration (preferred) or just to add a delay by trial and error (horrible)?
At the moment my /lib/systemd/system/camilladsp.service just waits for syslog:
Update
Funny how describing the problem focuses the mind... Immediately after posting I found out how to just delay any service start... and it all works as expected and hoped for, but I would still much prefer to avoid ad-hoc delays by using a suitable "After" rule!
If no better (e.g. "After") solution turns up, then here is how to fix it with a delay in the /lib/systemd/system/camilladsp.service:
Looking at the logs this seems to be because the ALSA hdmi playback device it is not (yet) available. If I restart the service manually after the boot it then always succeeds.
Unsuccessful service start at boot:
Successful manual service restart a short time later:
Is there a way to make the camillaDSP service start conditional on the ALSA HDMI device enumeration (preferred) or just to add a delay by trial and error (horrible)?
At the moment my /lib/systemd/system/camilladsp.service just waits for syslog:
Update
Funny how describing the problem focuses the mind... Immediately after posting I found out how to just delay any service start... and it all works as expected and hoped for, but I would still much prefer to avoid ad-hoc delays by using a suitable "After" rule!
If no better (e.g. "After") solution turns up, then here is how to fix it with a delay in the /lib/systemd/system/camilladsp.service:
Last edited:
Typically a udev rule is used for these tasks. Look at https://github.com/HEnquist/camilla...v-rule-to-start-service-when-dac-is-connected - just instead of the USB ID rule for a USB device use a rule for device name - similar to https://askubuntu.com/questions/354612/how-to-run-a-script-when-i-connect-a-device
I assume the os device to target is "/dev/dri/card0"
I'll give this all a try but...
I'll give this all a try but...
- Does this risk starting before "syslog"? (I assume not due to the U in udev)
- Does this guarantee to fix the problem? Is the device visible in ALSA environment as soon as the os device appears, or at least before udev triggers?
Alsa devices are in /dev/snd/cardXX.
I am afraid I do not understand, why?
udev is a user-space daemon (today part of systemd) which manages the dev virtual filesystem in /dev, based on uevent messages sent from the kernel and on its rules. See e.g. https://en.wikipedia.org/wiki/Udev + lots of info online.
A device is "visible in ALSA environment" when its /dev/snd/... device file is created. "ALSA environment" is just a library alsa-lib (libasound2...), linked to executables using alsa (clients). Clients must enumerate/check for the available devices (via alsalib, of course). If a client wants to know a new device was created (e.g. pulseaudio), it must listen to udev events - https://stackoverflow.com/questions/36975381/alsa-callback-when-new-card-device-is-added .
Using udev rules for actions on newly created/removed/anything devices is the standard method.
Thanks. This is the key to my puzzle: That alsa devices are indeed represented in the file-system! (I couldn't "find" any devices matching the alsa names like "hdmi" "Loopback" etc. so I assumed they were some sort of user-space objects interfaced via the alsa library.)
My next puzzle... Which snd devices correspond to the alsa "hdmi0/1" devices?