On Sat, 2014-07-05 at 18:58 +0200, Michael Biebl wrote:
Am 05.07.2014 18:38, schrieb Antonio Marcos López Alonso:
El 05/07/14 17:06, Michael Biebl escribió:
Am 05.07.2014 17:56, schrieb Antonio Marcos López Alonso:
Just in case, have you noticed I'm using an ALSA-Jack loopback setting
for audio?
Under sysvinit, udev (including udevadm settle) is started before the
kmod init script, which loads snd_aloop.
That means, snd_aloop is loaded after snd_hda_intel.
Under systemd, it looks like the snd_aloop module is loaded about the
same time systemd-udevd is started. There might be a race here and
snd_aloop is loaded before snd_hda_intel.
This *might* be the reason, but I'm no expert on this matter.
Can you try removing snd_aloop from /etc/modules and test if that makes
a difference.
OK removed snd_aloop and audio is back. Then reloaded the module,
restarted JACK and audio is still fine. So as you said there must be
some race condition in there. Should I keep this ticket opened?
Hm, not sure what to do about this. We could order
systemd-load-modules.service after systemd-udevd.service. But that
doesn't guarantee the loading order of the modules and it feels like
papering over the underlying issue.
I'm no sound expert, but I'd say that the loading order should not
matter. Maybe we need some input from the kernel team or some alsa
experts here.
I think this is due to ALSA userland (or maybe higher levels) being
stupid about device selection. I think the default is to use sound
device 0, which can be whichever driver won the race.
I took the liberty to CC the Debian kernel team and the maintainer of
the snd_aloop module. I hope they can help us here.
For reference the complete bug report is at [1]
Michael
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753816
I think the usual workaround is to add 'index=1' to the snd-aloop line
in /etc/modules. It is probably possible to do something more
sophisticated in an ALSA configuration file.
Ben.