[LAD] Problem with recent hdspm, alsactl and systemd

[Dominique Michel]

Le Thu, 13 Jun 2013 22:02:48 +0000,
Fons Adriaensen <fons at linuxaudio.org> a écrit :

> Hello all,

Hello Fons,

> 
> I wonder if any other users have experienced this problem and
> how they handled it.
> 
> This has occured three times when doing an fresh Archlinux install
> on a system using the RME MADI cards.
> 
> There seems to be something in the combination of recent versions
> of the driver and alsactl that leads to alsactl freezing when the
> configured (external) clock source for the card is not available.
> The 'freeze' seems to be quite deep: it's impossible to kill the
> process (even while that process is still a child of e.g. the 
> xterm from which it was launched, and not of PID 1). Any other
> process trying to access the sound card (e.g. jackd) hangs in
> the same way. This also means that when doing a poweroff or reboot
> systemd will hang on the 'alsactl store' service, and the only
> option is a power cycle.
> 
> An added difficulty when trying to resolve this (things will be
> OK once you have the correct /var/lib/alsa/asound.state) is that
> recent systemd doesn't allow to disable or enable the alsa store/
> restore services easily (why not ?), you have to manually edit 
> some symlinks in order to do that. 

I don't know systemd at all. As a temporary workaround for alsa
store/restore, maybe you can mask the module
in /etc/modprobe.d/blacklist.conf and load it later.

 
> Note: if this happens to be a driver problem, please do NOT revert
> to the ancient behaviour of silently changing the clock source to
> 'internal' when the external clock is not available. I DO still
> expect to see opening the device fail if the external clock isn't
> present, as has been the case for some time. The thing that shouldn't
> happen is that alsactl chokes on this condition - it didn't before
> so it shouldn't have to.
> 
> Ciao,
> 


-- 
"We have the heroes we deserve."