[systemd-devel] alsa-restore.service seems to be too early

Colin Guthrie gmane at colin.guthr.ie
Tue Sep 11 05:17:23 PDT 2012

'Twas brillig, and Lennart Poettering at 11/09/12 13:12 did gyre and gimble:
> On Tue, 11.09.12 11:15, Colin Guthrie (gmane at colin.guthr.ie) wrote:
>>>> Yes, thanks, sleeping does help (the card under question is the second one, i.e. with suffix '1'):
>>>> ~ $ cat /etc/udev/rules.d/99-zlocal.rules | grep alsa
>>>> ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC1", KERNELS=="card1", RUN+="/usr/local/bin/realsa.sh"
>>>> ~ $ cat /usr/local/bin/realsa.sh
>>>> #!/bin/bash
>>>> sleep 1
>>>> /usr/sbin/alsactl restore
>>> What is the problem here? Why do you need the sleep 1? Normally
>>> /usr/lib/udev/rules.d/90-alsa-restore.rules (which is shipped as part of
>>> ALSA) should just make this all work. It will fix the volumes as soon as
>>> the control device shows up. 
>> Well I think in this case the problem is that the card somehow doesn't
>> accept input until slightly after it advertises itself as being
>> available, thus the sleep allows it to work.
>> I'm not sure where the real problem lies, whether it's in udev, some
>> sort of firmware loading thing, the kernel driver or something else. I
>> figured you'd probably have some kind of clue as to where in the stack
>> the problem is likely to lie.
> Ah, this is a sound card which requires firmware? 

For the avoidance of doubt, I have no idea if this specific card does
require fireware or not - this was a "could be one of these" suggestions
I was throwing into the melting pot.

The original reporter can maybe confirm if firmware is involved - I
think he also mentioned USB at one point so that might also be some



Colin Guthrie

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

More information about the systemd-devel mailing list