Hotplugged sound devices get sound card index of 0 instead of PCI card

Bug #46996 reported by fubarbundy
64
This bug affects 2 people
Affects Status Importance Assigned to Milestone
alsa-driver (Ubuntu)
Fix Released
Wishlist
Unassigned

Bug Description

To reproduce: on a machine with a working sound card at index 0 (listed in gnome-volume-control under file/change device as '0: xxxx', plug in a USB sound device (especially something like a microphone, webcam etc.) Reboot.

Result: USB device steals index 0 and ALSA assigns it default status. Any other programs using /dev/dsp break.

Expected result: PCI and other internal devices get assigned lowest indexes first, ensuring they have a dependable device node. USB devices then get given higher indexes/nodes as they are less permanent.

Revision history for this message
fubarbundy (launchpad-mailtic) wrote :

Damn. Wrong package. Sorry.

Revision history for this message
Daniel T Chen (crimsun) wrote :

Not fixable for Dapper. In the meantime, use System> Preferences> Sound> default sound card's drop-down menu, or use asoundconf(1) directly.

Revision history for this message
Marco Cimmino (cimmo) wrote :

in Kubuntu there is no default selectable.
Is fixed for Edgy?

Revision history for this message
Elez (elez) wrote :

This bug remains in Edgy so far.

Revision history for this message
Daniel T Chen (crimsun) wrote :

The only thing that can be done currently is to work around it by using /etc/modprobe.d/alsa-base. I'm not a fan of this approach, because it will silently break the semantics of current installs, but you can use:

options snd-usb-audio index=-1

Currently, the following is applicable:

Use case: I have an M-Audio Transit USB. I _want_ it to be the default sound device. It works that way on boot. I'm happy.

Use case: You have a USB Webcam. You _don't_ want it to be the default sound device. It doesn't work that way on boot. You're not happy.

Use case: Jane Doe has a USB MIDI device. She doesn't care whether it's default.

Now if we make the above change, presuming that the user doesn't already have an ~/.asoundrc* (or /etc/asound.conf), then my use case breaks (I'm not happy), your use case succeeds (you're happy), and Jane's use case still is moot.

In other words, it's a no-win situation particularly because forcing any USB sound device to a lower priority essentially necessitates the user having to use [something that invokes] asoundconf(1) [or writing out ~/.asoundrc* or /etc/asound.conf by hand], whereas formerly simply hotplugging the USB sound device after hardware drivers are loaded (fairly early in the boot sequence) "works".

Unfortunately, it looks like using asoundconf(1) is unavoidable for at least one of the use cases regardless which approach is used, so the /etc/modprobe.d/alsa-base approach will probably be made.

Changed in alsa-driver:
importance: Medium → Wishlist
status: Unconfirmed → In Progress
Revision history for this message
Elez (elez) wrote :

Daniel: I have to disagree with you on the "no-win situation".
Ubuntu is the only distro that I know that puts the hotplugged sound device as default.
People expect a certain behavior from their linux machine based on what they got accustomed to from using other distros and they don't get that with Ubuntu.

This is what bothered me the most, the fact that all other distros I came across behaved according to a certain rule that only Ubuntu would not adhere to.

Revision history for this message
Elez (elez) wrote :

and one more (very important) thing I forgot to mention:
Now, people are getting seemingly sporadic behavior. When they turn on their computer and their usb audio device is plugged in, all audio will go to it. When they turn on their computer and their usb audio device isn't plugged in, all audio will go to their regular sound card.
This kind of problem is insurmountable to the average Joe.

Revision history for this message
Daniel T Chen (crimsun) wrote :

@Elez: "seemingly erratic" is actually expected behaviour. Other non-Debian-based distros may have already applied an index parameter to USB sound devices driven by ALSA, but as far as I can tell, neither Debian nor Ubuntu has done anything of the like.

I would also consider the ability, in Dapper's GNOME, to change the default sound card using the System> Preferences> Sound> Set default sound card menu item something considerably less ominous than "insurmountable".

Nevertheless, I'll add the options line for snd-usb-audio soon.

Revision history for this message
Elez (elez) wrote :

Daniel: What do Kubuntu users (like myself) do to solve this?

Revision history for this message
Daniel T Chen (crimsun) wrote :

@Elez: The same thing we Xfce users do, which is to call asoundconf(1) directly (which is what gnome-control-center's applet does anyhow).

$ asoundconf list

should return strings of recognised drivers. Then use:

$ asoundconf set-default-card string

as a convenience. Afterward restart all ALSA applications.

Revision history for this message
Elez (elez) wrote :

Daniel: EXACTLY! Now you can read my dramatic post with the "insurmountable" :)

Revision history for this message
Daniel T Chen (crimsun) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Thu, 17 Aug 2006 00:34:10 +0100
Source: alsa-driver
Binary: linux-sound-base alsa-source alsa-base
Architecture: source
Version: 1.0.11-5ubuntu1
Distribution: edgy
Urgency: low
Maintainer: Debian ALSA Maintainers <email address hidden>
Changed-By: Daniel T Chen <email address hidden>
Description:
 alsa-base - ALSA driver configuration files
 alsa-source - ALSA driver sources
 linux-sound-base - base package for ALSA and OSS sound systems
Closes: 377716 380490
Changes:
 alsa-driver (1.0.11-5ubuntu1) edgy; urgency=low
 .
   * Merge from Debian unstable. The following Ubuntu changes remain:
     - Only ship modprobe configuration,
     - Remove default mode,
     - Invoke modprobe with -Qb and command line options,
     - Remove modprobe post-install script in favour of using udev,
     - Merge Debian 1.0.11-5's apm script into the initscript, and
       continue to ship the initscript in the apm scripts dir,
     - Don't allow snd-usb-audio to grab the default index, 0
       (Closes Ubuntu: #31109, #46996, #46998).
 .
 alsa-driver (1.0.11-5) unstable; urgency=low
 .
   [ Elimar Riesebieter ]
   * Added mixer store and restore functions to the apm script.
     (closes: #380490)
 .
 alsa-driver (1.0.11-4) unstable; urgency=low
 .
   [ Elimar Riesebieter ]
   * Use lsb init-functions in init script. Thanks Carlos Villegas
     (closes: #377716)
Files:
 256738ac1bf8a5fd5d259728a06012d4 805 sound optional alsa-driver_1.0.11-5ubuntu1.dsc
 4a14e37eaba5b34a4484c35f32d7c27b 181583 sound optional alsa-driver_1.0.11-5ubuntu1.diff.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
iD8DBQFE9PTQe9GwFciKvaMRAlbTAJ9WqByCuFG+CmeLEKa4bvBOup3zkQCeOUhz
cfhL+mgqvSud2s/RSyyhEPU=
=5vwS
-----END PGP SIGNATURE-----

Changed in alsa-driver:
status: In Progress → Fix Committed
Daniel T Chen (crimsun)
Changed in alsa-driver:
status: Fix Committed → Fix Released
Revision history for this message
Matthew Craig (matthew-t-craig) wrote :

Daniel, I have just finished fighting with this "default ALSA card not found" issue for several days, and I came to Launchpad to file a bug report, when I saw this one referenced.

I disagree with the approach of using asoundconf set-default-card <string> because (a) the user is not given information what the string should be, (b) the command does not error when the user has chosen the wrong string, and (c) that asoundconf command is not universal - there are still SDL applications that are unable to find a default card.

My work around that I wanted to share was:
(1) Get the card's module name with the command: cat /proc/asound/modules
(2) With sudo, edit the file: /etc/modprobe.d/alsa-base
(3) Insert into the last line: options <module name> index=0
(4) Restart ALSA with: sudo /etc/init.d/alsa-utils restart

I believe Ubuntu should handle these steps during installation, as this is a painful process for new users to get basic sound functionality.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.