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

Colin Guthrie gmane at colin.guthr.ie
Tue Sep 11 03:15:49 PDT 2012


'Twas brillig, and Lennart Poettering at 11/09/12 02:12 did gyre and gimble:
> On Mon, 03.09.12 14:34, Вечный Студент (student975 at yandex.ru) wrote:
> 
>>
>> 03.09.2012, 13:48, "Colin Guthrie" <gmane at colin.guthr.ie>:
>>> Then you should probably try and debug this further - e.g. by rmmod'ing
>>> the module and inserting it and trying to work out why it's not run. You
>>> can always replace the rule with one that runs a script instead that
>>> writes debugging info or similar.
>>>
>>> In theory the control device should appear last to udev (something which
>>> we had to fight with a few years back with PulseAudio). When the control
>>> device appears it should be all ready. The only complication that I can
>>> think of is that there might be some kind of firmware loading issue that
>>> means that the control device appears before the device can really be used.
>>>
>>> If you do replace it with a script, try introducing a sleep in it
>>
>> 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.

Col




-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

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