Re: [LAD] Problem with recent hdspm, alsactl and systemd
On 06/14/2013 12:02 AM, Fons Adriaensen wrote: 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. i know i tend to over-estimate the power of strace, but you could try to run the offending process manually and watch it very closely: root:~> strace /usr/sbin/alsactl store maybe this gives you an idea where stuff goes wrong. -- Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio) Tonmeister VDT http://stackingdwarves.net ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Problem with recent hdspm, alsactl and systemd
Le Fri, 14 Jun 2013 10:35:35 +0200, Dominique Michel a écrit : > Le Thu, 13 Jun 2013 22:02:48 +, > Fons Adriaensen 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. Obviously, this will not work with alsa store. > > > > 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." ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Problem with recent hdspm, alsactl and systemd
Le Thu, 13 Jun 2013 22:02:48 +, Fons Adriaensen 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." ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
