Some audio devices should not be selected as the default

[Sebastian Breier]

Sound doesn't work after installation.

I got an SB Live! Value, driver emu10k1 is loaded.
If I use the default MP3 player, it tries to access /dev/dsp, and says it
doesn't exist. It probably does exist, but can't access the sound card.

If I delete /dev/dsp and create a link to /dev/dsp1, it works perfectly. After
the next reboot, /dev/dsp is not the link anymore, it's the default file again,
and /dev/dsp doesn't work.

I have no idea what's wrong.

[Sebastian Breier (tomcat42)]

This was a long bug hunt...

The problem has been identified and a workaround is being provided at:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=106748

The problem: I got two audio devices, one is a Brooktree TV card, one is a
regular sound card (SB Live! Value, emu10k1).

When the modules are automatically loaded for the devices, the tv card's sound
driver (snd_bt87x) gets loaded first, after that snd_emu10k1 is being loaded.
That makes the TV card go to /dev/dsp, the sound card to /dev/dsp1.

To switch it around, I added the following (from the mentioned website, just
changed for my needs) to /etc/modprobe.d/aliases:

alias snd-card-0 snd_emu10k1
options snd_emu10k1 index=0

alias snd-card-1 snd_bt87x
options snd_bt87x index=1

This makes the sound card use /dev/dsp, the TV card uses /dev/dsp1. Everything fine.

This should be improved, but I don't know who's responsibility this is. I
changed the severity to 'enhancement' because it would be nice if fixed. Set the
bug to FIXED if this has to be done by somebody else than the Ubuntu team.

[Matt Zimmerman (mdz)]

This is a tricky problem. For what it's worth, you could fix the problem once
and for all by swapping the order of the PCI cards.

In the long term, we should probably have a blacklist of audio devices which
should not be the default (bttv, modems, etc.), and enforce it. I'm not sure
what the best implementation would be, though, since currently the devices are
scanned in PCI order, so we don't get a chance to "go back" and add a device as
a secondary sound card if we skip it the first time around

[Jeff Waugh (jdub)]

So, PCI ordering seems annoying. :-) Possibly an easier one: deprioritising USB
devices behind PCI devices. I had the same issue occur with my webcam USB
capture device.

[Matt Zimmerman (mdz)]

*** Bug 8223 has been marked as a duplicate of this bug. ***

[Matt Zimmerman (mdz)]

*** Bug 8842 has been marked as a duplicate of this bug. ***

[Matt Zimmerman (mdz)]

*** Bug 8820 has been marked as a duplicate of this bug. ***

[Matt Zimmerman (mdz)]

*** Bug 8884 has been marked as a duplicate of this bug. ***

[Matt Zimmerman (mdz)]

*** Bug 9168 has been marked as a duplicate of this bug. ***

[bluegeek (bluegeek)]

I've reisntalled ubuntu using the release ISO and now my soundcard is configured as first
device (instead of my TV card like the first time I installed ubuntu). So now sound just
works (tm) out of the (cd-rom)box :) BTW what was changed in the packages?

[Matt Zimmerman (mdz)]

(In reply to comment #9)
> I've reisntalled ubuntu using the release ISO and now my soundcard is
configured as first
> device (instead of my TV card like the first time I installed ubuntu). So now
sound just
> works (tm) out of the (cd-rom)box :) BTW what was changed in the packages?

That's very surprising, considering that nothing has really changed in this
area. :-)

[Sebastian Breier (tomcat42)]

It's no coincidence...

When I reinstalled a daily Ubuntu to test another issue, it was the same...
sound from the first boot.
I really doubt nothing has changed. :)

[Matt Zimmerman (mdz)]

(In reply to comment #11)
> It's no coincidence...
>
> When I reinstalled a daily Ubuntu to test another issue, it was the same...
> sound from the first boot.
> I really doubt nothing has changed. :)

OK, how about this: if the behaviour has changed, it is coincidental,
unintentional and has not fixed the bug for others. :-)

[Kristof Vansant (de-lupus)]

It should be possible in gnome to just select the output device you want.
People with 2 sound cards would want to be able to select which/both soundcard
for output. Without rebooting.

[Matt Zimmerman (mdz)]

Agreed, but regardless of that, we should avoid having a webcam, btaudio or
modem device be chosen as the primary sound device

[Thomas Hood (jdthood)]

This bug was also reported to Debian (#282602) and to RedHat
   http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=106748
and the issue has been raised at linux-hotplug-devel
   http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=110138425812621&w=2

[Thomas Hood (jdthood)]

RedHat fixed this by doing something to kudzu and/or system-config-soundcard.
I don't know the details.

This problem is a lot like the problem of network interfaces being named
differently on different occasions. There are two ways to solve the latter
problem other than the obvious (ugly) one of enforcing the loading of the
driver in a particular order. One solution is to use a utility such as
ifrename which assigns a stable name to the interface after it is created.
The other is to modify applications that use network interfaces so that
they don't rely on the interface name when they choose interfaces to
operate on, but look for distinguishing properties of the interfaces
instead.

The "index" option on the ALSA modules offers some control over the
card numbers. Suppose we configure known cards so that they are loaded
with indexes starting at, e.g., 8. Then "unknown" cards loaded earlier
or later won't prevent the known card from being assigned index 8.

Can we do the equivalent of ifrename using libasound2 plugins?

--
Thomas Hood

[Matt Zimmerman (mdz)]

Thanks for the external references. We currently address the network interface
naming issue by using ifrename, writing an /etc/iftab file in the installer.
The equivalent approach for ALSA would be to add some code to /etc/init.d/alsa
which writes an /etc/modprobe.d file with the appropriate 'index' options (if it
doesn't already exist). How does that sound?

[Matt Zimmerman (mdz)]

Marco d'Itri pointed out on IRC that it would also be possible to solve this
problem by binding device names to a specific PCI ID, a method which he said
would also work for network cards. I like the idea of a generic solution based
on bus identifiers very much.

What would be involved in implementing this?

[Thomas Hood (jdthood)]

(In reply to comment #17)
> Thanks for the external references. We currently address the network interface
> naming issue by using ifrename, writing an /etc/iftab file in the installer.
> The equivalent approach for ALSA would be to add some code to /etc/init.d/alsa
> which writes an /etc/modprobe.d file with the appropriate 'index' options (if it
> doesn't already exist). How does that sound?

Adding "index" options may be the best solution for now.

However, I don't see why you would want the ALSA initscript to write modprobe
configuration files. Shouldn't this, too, be done by the installer?

[Thomas Hood (jdthood)]

(In reply to comment #18)
> Marco d'Itri pointed out on IRC that it would also be possible to solve this
> problem by binding device names to a specific PCI ID, a method which he said
> would also work for network cards. I like the idea of a generic solution based
> on bus identifiers very much.

Sounds like a job for udev.

[Matt Zimmerman (mdz)]

I don't like relying on the installer for this; it causes problems when new
hardware is added after installation. The situation with network interfaces is
not ideal for this reason.

For example, some wireless cards are (were?) not usable in the installer, but
were usable in the installed system, making this a common occurrence.

I think the udev solution sounds great. Can someone explain how this mechanism
works, or provide pointers to such information, so that we can start
implementing it?

[Matt Zimmerman (mdz)]

Marco d'Itri pointed out this guide on IRC:

http://www.reactivated.net/udevrules.php

which seems to provide the needed information about the implementation.

Another decision that needs to be made is how to name the devices. It seems we
could:

- Allocate the usual numbered names (e.g., dsp, dsp1, dsp2), but ensure that
they are persistent even when devices are added or removed. For example, if a
system has dsp and dsp1, and the device corresponding to dsp is removed, only
dsp1 would remain. If a new device were added, it would become dsp2. This is
confusing, but consistent

- Some variant of the above which ensures that there is always _something_ at
the default device location (e.g., /dev/dsp), but retains some consistency

- Allocate the names according to some other scheme (such as?)

[Kristof Vansant (de-lupus)]

Can't we let alsa tell us trough sysfs what kind of audio device we are dealing
with.

Interresting would be if it could tell us if it had input and/or output audio.

if it has output audio udevd may put it as /dev/dsp otherwise as another name.

or could alsa tell us what type of device the hardware is a webcam audio
controller, tv audio controller or main audio controller.

if udev sees it is a main audio controller it will put it as /dev/dsp otherwise
as another name.

this looks like the easiest way for udev to know how to make a selection.

This would solve the webcam etc getting /dev/dsp as device name if first detected

[Thomas Hood (jdthood)]

It should be pointed out that this problem afflicts OSS drivers as well
as ALSA drivers. I am inclined not to bother fixing the problem for OSS
drivers unless the solution we find for ALSA happens to extend easily to
the OSS case.

Matt Zimmerman wrote:
> Another decision that needs to be made is how to name the devices.

For alsa devices I currently have:

/dev/snd/
    controlC0
    midiC0D0
    pcmC0D0c
    pcmC0D0p
    timer

We could make this:

/dev/snd/card.<some_id>/
    control
    midiD0
    pcmD0c
    pcmD0p
    timer
/dev/snd/card.<another_id>/
    control
    midiD0
    pcmD0c
    pcmD0p
    timer
/dev/snd/
    card0 -> card.<some_id>
    card1 -> card.<another_id>
    controlC0 -> card0/control
    ...

The mapping from card* to card.* would reflect a fixed order of priority among
sound card models. This would provide the desired stability across reboots.
Applications needing to address a particular sound card could use the devices
in /dev/snd/card.<id>/. An application that just wanted to open the "primary"
sound card would use /dev/snd/pcmC0D0p as before.

The "id" is the ALSA I.D. Sound card modules can be loaded with an "id" option.
E.g., normally I see this in /proc/asound/cards:

    0 [CS46xx ]: CS46xx - Sound Fusion CS46xx
                     Sound Fusion CS46xx at 0x50100000/0x50000000, irq 11

but if i put this line in /etc/modprobe.d/sound:

    options snd-cs46xx id=foofoo

I see this in /proc/asound/cards:

    0 [foofoo ]: CS46xx - Sound Fusion CS46xx
                     Sound Fusion CS46xx at 0x50100000/0x50000000, irq 11

I don't know exactly what other effects the id has. For one thing,
mixer settings are stored under the name "state.<id>" in
/var/lib/alsa/asound.state.

[Thomas Hood (jdthood)]

On second thought, the information that udev would use to set up the
symlinks as I described earlier is already available to applications
via /proc/asound/cards; so, introducing /dev/snd/card.<id>/ is not
really necessary. E.g., suppose an application wants to talk to a
CS46xx. Instead of trying to open /dev/snd/card.CS46xx/pcmD0p (as
I suggested) the application can look in /proc/asound/cards, find
that there is a CS46xx at index 0 and open /dev/snd/pcmC0D0p .
Alternatively, it could look for the card by card ID.

I am having doubts that we should configure udev so that it puts
card index numbers in a certain order based on card type or PCI ID.
It would be hard to make this work reliably when hot plugging is
possible. We don't want devices changing indices when other cards
are inserted or removed and that restriction makes it impossible
to guarantee that the cards are always indexed in the "appropriate"
order. Furthermore, the order that is "appropriate" depends on
which application we are thinking about.

Having said that, I do think that it would be worthwhile to do
something on behalf of the simplest sound applications which expect
to be able to play sounds by opening /dev/snd/pcmC0D0p or /dev/dsp.

Perhaps it would suffice if we made a list of drivers that drive
cards that are inherently unsuitable to be the primary sound card.
I take it that snd-bt87x is such a driver because it only does
recording, no playback. There may be others (e.g., the modems?).
For each of these drivers we could add lines like these to
/etc/mod(utils|probe.d)/alsa-base:

    options snd-bt87x index=1

so that they don't get assigned index 0.

This scheme has a weakness. If the "index" option is not used
then ALSA assigns the first available index. If the "index"
option _is_ used the ALSA does not assign the first available
index; it only tries to assign the specified index and fails
if that index is already taken. Our scheme would be better if
we could get ALSA to implement a feature like this:

    options snd-bt87x index=1-

where "1-" means "1 or higher". However, even without this
enhancement I think that excluding the drivers in question from
getting index 0 is more important than supporting systems that
have three or more sound cards.

Comments?

[Daniel T Chen (crimsun)]

The workaround I've been suggesting to people using Warty is to hard-wire the
ALSA driver load order in /etc/modules, for example:

$ echo "snd-sb16" | sudo tee -a /etc/modules
snd-sb16
$ echo "snd-bt87x" | sudo tee -a /etc/modules
snd-bt87x

The sb16 card becomes ALSA's card0; the bt87x card becomes card1. It certainly
is less than optimal, but "it works."

Now when the fun (or forehead-bashing) begins is at the moment a user wishes to
use ALSA in conjunction with OSS/Free (e.g., snd-emu10k1 and bttv). Just
recently I suggested a similar workaround to the above for that particular Warty
user - that is, loading bttv after snd-pcm-oss.

The proposal to enumerate a list of "preferred" devices sounds promising, but I
agree it can become troublesome quickly depending on the user's preferences. The
vast majority of [new] ALSA users seem to have cards driven by snd-emu10k1,
snd-intel8x0, or snd-via82xx. Perhaps we should prefer one of those for card0 in
the presence of multiple cards of which only one card is driven by one of those
three drivers?

[Matt Zimmerman (mdz)]

*** Bug 11333 has been marked as a duplicate of this bug. ***

[Matt Zimmerman (mdz)]

*** Bug 11614 has been marked as a duplicate of this bug. ***

[Matt Zimmerman (mdz)]

(In reply to comment #25)
> Perhaps it would suffice if we made a list of drivers that drive
> cards that are inherently unsuitable to be the primary sound card.
> I take it that snd-bt87x is such a driver because it only does
> recording, no playback. There may be others (e.g., the modems?).
> For each of these drivers we could add lines like these to
> /etc/mod(utils|probe.d)/alsa-base:
>
> options snd-bt87x index=1
>
> so that they don't get assigned index 0.
>
> This scheme has a weakness. If the "index" option is not used
> then ALSA assigns the first available index. If the "index"
> option _is_ used the ALSA does not assign the first available
> index; it only tries to assign the specified index and fails
> if that index is already taken. Our scheme would be better if
> we could get ALSA to implement a feature like this:
>
> options snd-bt87x index=1-
>
> where "1-" means "1 or higher". However, even without this
> enhancement I think that excluding the drivers in question from
> getting index 0 is more important than supporting systems that
> have three or more sound cards.
>
> Comments?

I think this would address the bulk of the problem in as simple way, and so I
quite like the idea.

Are the existing semantics of "I must use index N" useful enough that we should
not just override index=N to mean "N or higher"? That seems reasonable to me.

[Thomas Hood (jdthood)]

The current semantics of the "index" option are:

   >= SNDRV_CARDS invalid
   0..(SNDRV_CARDS-1) Assign that index
   -1 Assign the first available index between 0 and
(SNDRV_CARDS-1)

A natural way to extend this to meet our needs is to regard -1, i.e.,
0xffffffff, as a bitmask of permissible indices. Then TV cards and
modems can be loaded with index=-2, i.e. 0xfffffffe. The patch to
implement this is straightforward:

--- alsa-kernel/core/init.c_ORIG 2005-01-07 12:29:53.000000000 +0100
+++ alsa-kernel/core/init.c 2005-01-07 13:43:54.000000000 +0100
@@ -84,16 +84,13 @@
        write_lock(&snd_card_rwlock);
        if (idx < 0) {
                int idx2;
- for (idx2 = 0; idx2 < snd_ecards_limit; idx2++)
- if (!(snd_cards_lock & (1 << idx2))) {
+ for (idx2 = 0; idx2 < SNDRV_CARDS; idx2++)
+ if (~snd_cards_lock & idx & 1<<idx2) {
                                idx = idx2;
+ if (idx >= snd_ecards_limit)
+ snd_ecards_limit = idx + 1;
                                break;
                        }
- if (idx < 0 && snd_ecards_limit < SNDRV_CARDS)
- /* for dynamically additional devices like hotplug:
- * increment the limit if still free slot exists.
- */
- idx = snd_ecards_limit++;
        } else if (idx < snd_ecards_limit) {
                if (snd_cards_lock & (1 << idx))
                        err = -ENODEV; /* invalid */

A short console log shows that this works:

root@thanatos:~# cat /proc/asound/cards
--- no soundcards ---
root@thanatos:~# modprobe snd-dummy
root@thanatos:~# cat /proc/asound/cards
0 [Dummy ]: Dummy - Dummy
                     Dummy 1
root@thanatos:~# rmmod snd-dummy
root@thanatos:~# cat /proc/asound/cards
--- no soundcards ---
root@thanatos:~# echo "options snd-dummy index=-16" > /etc/modprobe.d/s
root@thanatos:~# # N.B., -16=0xfffffff0
root@thanatos:~# modprobe snd-dummy
root@thanatos:~# cat /proc/asound/cards
4 [Dummy ]: Dummy - Dummy
                     Dummy 1
root@thanatos:~# echo "options snd-cs46xx index=-16" >> /etc/modprobe.d/s
root@thanatos:~# modprobe snd-cs46xx
root@thanatos:~# cat /proc/asound/cards
4 [Dummy ]: Dummy - Dummy
                     Dummy 1
5 [CS46xx ]: CS46xx - Sound Fusion CS46xx
                     Sound Fusion CS46xx at 0x50100000/0x50000000, irq 11

[Thomas Hood (jdthood)]

I am thinking of implementing the solution described in my previous message
in the upcoming 1.0.7-3 release of the Debian alsa-driver package (= the
source for alsa-base and alsa-source). Upstream seems to have agreed[0]
to apply the patch, but not before the 1.0.9 cycle. I would apply the
patch locally until then and include the following in the module loader
configuration files:

    options snd-atiixp-modem index=-2
    options snd-bt87x index=-2
    options snd-bt87x-overclock index=-2
    options snd-intel8x0m index=-2
    options snd-via82xx-modem index=-2

This will cause these drivers to start looking for free indexes at 1,
rather than at 0.

Any objections?

[0] https://bugtrack.alsa-project.org/alsa-bug/view.php?id=359

[Matt Zimmerman (mdz)]

Sounds great. Fabio, what about getting this patch into our kernel?

[Matt Zimmerman (mdz)]

If we address the issue that some drivers should not be selected as default, the
remainder of the bug should be represented by bug #8107, which is that we have
no way to select a default sound device in the desktop.
So we can consider this bug only to be about that issue.

[Thomas Hood (jdthood)]

> If we address the issue that some drivers should not be selected as default,

(This has been done in Debian alsa-driver 1.0.8-1, just uploaded to sid.)

> the remainder of the bug should be represented by bug #8107, which is that
> we have no way to select a default sound device in the desktop. So we can
> consider this bug only to be about that issue.

Yes.

I will follow up at #1351.

[Fabio Massimo Di Nitto (fabbione)]

Sounds doable for me and the patch is not intrusive. We will need userland sync for
this to work properly.

Fabio

[Fabio Massimo Di Nitto (fabbione)]

Ok i am ready to upload the kernel with this patch. Matt i would like a GO from you
and get someone to sync userland as needed.

Fabio

[Thomas Hood (jdthood)]

> get someone to sync userland

I don't know what is required for Ubuntu -- I'm just one of the
Debian maintainers. However it might be useful if I pointed out
that adding these entries to the module loader config:

    options snd-atiixp-modem index=-2
    options snd-bt87x index=-2
    options snd-bt87x-overclock index=-2
    options snd-intel8x0m index=-2
    options snd-via82xx-modem index=-2

can be done before the ALSA drivers are patched; they will have no
effect because, without the patch, ALSA interprets all negative
values for "index" the same way and the default value is -1.
Conversely, the kernel can be patched without adding these entries.
So there is no need to make the kernelland and userland changes in
sequence.

[Fabio Massimo Di Nitto (fabbione)]

Fixed in 2.6.10-9 upload (kernel side!)

[Thomas Hood (jdthood)]

One other thing I should mention. In the /etc/mod(utils|probe.d)/alsa-base
files that shipped with alsa-base 1.0.8-1 the list of options lines is
different from the one I presented earlier (... IIRC; I am on a Windows
machine right now and can't check). In particular, I think that the
line for snd-bt87x-overclock is absent because this driver is disabled in
the 1.0.8-1 release. The list may change in 1.0.8-2 too, depending on
what I find out about the snd-bt87x-overclock driver.

Just a heads up in case Ubuntu is doing work parallel to Debian's.

[Matt Zimmerman (mdz)]

(In reply to comment #39)
> One other thing I should mention. In the /etc/mod(utils|probe.d)/alsa-base
> files that shipped with alsa-base 1.0.8-1 the list of options lines is
> different from the one I presented earlier (... IIRC; I am on a Windows
> machine right now and can't check). In particular, I think that the
> line for snd-bt87x-overclock is absent because this driver is disabled in
> the 1.0.8-1 release. The list may change in 1.0.8-2 too, depending on
> what I find out about the snd-bt87x-overclock driver.
>
> Just a heads up in case Ubuntu is doing work parallel to Debian's.

Is 1.0.8 a fairly safe thing to bring into a release which is headed for
stabilization? (e.g., do you consider it appropriate for Sarge)?

If, in your opinion, it's a reasonably safe thing to do, then I'm fine with
bringing it into Hoary.

[Thomas Hood (jdthood)]

> Is 1.0.8 a fairly safe thing to bring into a release which is headed for
> stabilization? (e.g., do you consider it appropriate for Sarge)?

1.0.8-1 is significantly improved over the last 1.0.7 release. However,
because so many different changes were made, I do expect that some bugs
will turn up. Someone has already filed #290995, for example.

Bugs aside, I want to add basic support for the new --with-card-options
option that has been added to the configure script. I have already
checked in the changes for this. We will probably release alsa-driver
1.0.8-2 before very long in order to address these issues.

So to answer your question: Yes, I think that 1.0.8-1 or -2 is fairly
safe and should be included in sarge.

[Matt Zimmerman (mdz)]

OK, we'll bring in -1 now, and probably -2 when it is released (if you could
send a reminder, that would be great). Thanks for your work on this issue.

[Matt Zimmerman (mdz)]

*** Bug 11815 has been marked as a duplicate of this bug. ***

[Thomas Hood (jdthood)]

> OK, we'll bring in -1 now, and probably -2 when it is released

#290995 turned out to be fixed in the 1.0.8-1 packages already,
so as of now I know of no regressions in 1.0.8-1 versus 1.0.7-*.
I still hope to release 1.0.8-2 before too long in order to add
"--with-card-options" support, but that is far from urgent.

For the record and presumably not relevant to ubuntu, in #291127 I
have requested that the negative-index-is-index-bitmask patch be
applied to Debian's 2.6.8 kernel.

[Fabio Massimo Di Nitto (fabbione)]

Both kernel and userland are now synced. Closing the bug.

Fabio

[Thomas Hood (jdthood)]

Further info: ALSA upstream plans[0] to merge the
negative-index-is-index-bitmask patch for the 1.0.8 release of
alsa-driver. They will also change the default index for modems
to -2.

[0] https://bugtrack.alsa-project.org/alsa-bug/view.php?id=359

[Thomas Hood (jdthood)]

I wrote:
> Further info: ALSA upstream plans[0] to merge the
> negative-index-is-index-bitmask patch for the 1.0.8 release

Sorry, make that "the 1.0.9 release".

[Thomas Hood (jdthood)]

Regarding Debian alsa-driver releases ...

We released 1.0.8-2 yesterday. It includes code to set reasonable
mixer levels in case "alsactl restore" does not succeed, plus a number
of other improvements.

Unfortunately I introduced bug #291942 which will necessitate a -3
release before too long. The changes required to fix #291942 are
minor and I don't plan to make any other big changes in -3.

[Matt Zimmerman (mdz)]

I've merged 1.0.8-2 into Hoary, thanks

[Thomas Hood (jdthood)]

alsa-driver 1.0.8-3 is now in Debian incoming.
Minor bugs were fixed.

[Matt Zimmerman (mdz)]

*** Bug 11134 has been marked as a duplicate of this bug. ***

[Thomas Hood (jdthood)]

alsa-driver 1.0.8-4 is now in Debian incoming.
A bug was fixed that caused the postinst to abort on some systems.
I am hoping that this is the release that can go out with sarge.

[M-M (mosneacs00)]

I have some problems similar to this,to the system sounds doesnt use my sound card, it just uses the onboard speaker, anyway when im finally logged in, everything is fine, the music is processed by the sound card, but the system sounds never sounds...

as soon as i return into the office y put the specifiactions
Thanks in advance!