[LAD] Problem with recent hdspm, alsactl and systemd

[Fons Adriaensen]

Hello all,

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. 

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,

-- 
FA

A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)