On Wed, 21 Apr 2021 21:59:00 +0200, Steven Skeard wrote:
Hi all,
I tried to get some help with this before but I don't think I articulated the problem very well and it seemed to fall between the cracks, so here I am to try again (https://mailman.alsa-project.org/pipermail/alsa-devel/2021-February/181262.h...).
With the default ALSA configuration in /etc/modprobe.d/alsa-base.conf, I experience a consistent race condition where if snd-usb-audio loads before snd-hda-intel, then the snd-hda-intel driver will fail to load with the -16 error as seen in the dmsg output at the end of this alsa info dump (http://alsa-project.org/db/?f=a23ccbb818fec6eaf08b032504eac5d5d8a30589). When this error occurs, I get a single dummy output and no working audio. In this state the only way to get working audio is to reboot my computer and hope things load in the correct order.
After much digging I found a couple links on the arch forums where people experienced similar problems (https://bbs.archlinux.org/viewtopic.php?id=264091, https://bbs.archlinux.org/viewtopic.php?id=260373). After reading both of those and looking at my dmsg outputs, I tested the following modifications to my modprobe configuration: 1. Remove the default line for the usb driver: "options snd-usb-audio index=-2" 2. Add a line to specify that the intel driver should be loaded first: "options snd-hda-intel index=0" 3. Add a line to specify that the realtek codec driver should be loaded second: "options snd-hda-codec-realtek index=1" 4. Add a line to specify that the usb driver should be loaded third: "options snd-usb-audio index=2" And this works, and not only works but works every reboot! I have uploaded an additional alsa info with the work around applied (http://alsa-project.org/db/?f=f2d90b82434ba89b834a67eaefe10726d538e829)
So while at the end of the day I have a working audio configuration, I can't help but feel like this is a bug. But the question I have is whether this is a bug with ALSA, or with the kernel driver? And how do I properly report this so it can be fixed?
Overall this is no bug, but rather a configuration failure.
First off, on modern systems with a sound backend like PulseAudio, the driver loading order doesn't matter much. So, at best, drop all the relevant module options.
On the system that still needs some level of static device order (e.g. the onboard device must appear in the primary card#1), this can be rather controlled via "slots" option of snd module. You can pass the driver names to reserve the card slots. e.g. passing options snd slots=snd_hda_intel,snd_usb_audio would assure the first card assigned to HD-audio while the second to USB.
Note that you'd still need some tweaks via index option of each driver in combination of slots option above, if there are multiple instances supported by a single driver (e.g. HD-audio onboard audio and HDMI controllers).
Takashi