Accepted alsa-utils 1.0.9a-4ubuntu1 (source)

[Thomas Hood]

Matt Zimmerman wrote:
> As I recall, we removed alsaconf because
> it would create /etc/modprobe.conf and thereby disable all of the
> /etc/modprobe.d/* stuff.  Would it be feasible to fix alsaconf to use
> /etc/modprobe.d/alsaconf or such instead, so that we could eliminate
> this patch as well?


alsaconf now writes /etc/mod(utils|probe.d)/sound.  (The file name
was chosen before I got involved.  I think that 'alsaconf' would
have been better, but it doesn't matter much.)  So it doesn't
break the module loader any more.  :)

First some background information.

At one time alsaconf was important because it wrote the one and
only module loader configuration file for ALSA.  Now most of the
useful stuff has been put into /etc/mod(utils|probe.d)/alsa-base
which is a conffile of alsa-base.  alsaconf only writes two lines
like the following to /etc/mod(utils|probe.d)/sound:

     alias snd-card-0 $CARD_DRIVER
     options $CARD_DRIVER index=0 $CARD_OPTS

These lines can't be moved to /etc/mod(utils|probe.d)/alsa-base
because they depend on the card driver that alsaconf detects.

The "snd-card-0" alias is needed by ALSA's special module loading
mechanism.  AIUI, when a sound application tries to play sound on
card #0, libasound tells the snd module about this and snd does a
modprobe on "snd-card-0" which, via the alias, loads the required
sound card driver.  I am told that the mechanism doesn't work
properly on udev systems.  I can guess the reason why: libasound
presumably proceeds as soon as the module is loaded, whereas on
udev systems the device node doesn't appear until some time later.
So the alias, although not entirely useless, is rather unimportant.

The "index=0" option is also rather unimportant.  It prevents the
driver from loading unless it can grab index 0, consistently with
its name being the value of the "snd-card-0" alias.  The main
benefit of the line is that it serves as a good example for someone
adding a second pair of lines to the file for a second sound card.

     alias snd-card-1 $CARD_DRIVER_1
     options $CARD_DRIVER_1 index=1 $CARD_1_OPTS

The "index=1" option is slightly more useful insofar as it
prevents $CARD_DRIVER_1 from grabbing index 0 if it happens to
be the first to initialize.  This prevents the phenomenon of two
sound cards having the opposite indices on subsequent boots.
However, this isn't very important any more.  The problem just
described was only ever reported by people whose second card
driver was a modem driver, and modem drivers are now globally
forbidden to grab index 0.  Furthermore, there is a better way
to deal with drivers playing "musical indexes": cards should
be opened by name rather than by index.

That leaves the "$CARD_OPTS" options.  I think that these are
only required for ISA cards.  I am not sure.

To sum up: alsaconf may not be entirely useless but its value
is slight.  I think that the program is even less valuable to
Ubuntu users than to Debian users, since udev is standard in
Ubuntu and Ubuntu discourages the use of tools that have to
be run as root in a terminal window.  The only reason I have
retained alsaconf in Debian is that I sometimes see reports
like this:

     Sound works after I run alsaconf but only until
     I reboot.  I have to run alsaconf every time!

In such cases the user can solve the problem by adding the
appropriate module name to /etc/modules.  Such reports indicate,
however, that alsaconf continues to have some value as a
hardware detector and as a diagnostic aid.

The down side of retaining alsaconf, aside from the fact that
it requires a lot of patching, is that its presence abets the
misapprehension many users have that they _need_ to run alsaconf
in order to "set up" their soundcard.

Eventually I will succumb to the urge to eliminate alsaconf
from Debian alsa-utils and then the last remaining difference
between the Debian and the Ubuntu packages can go away.  :)
-- 
Thomas