Bug 188033 - system-config-soundcard misses usb audio when multiple cards present
system-config-soundcard misses usb audio when multiple cards present
Product: Fedora
Classification: Fedora
Component: system-config-soundcard (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Martin Stransky
Depends On:
  Show dependency treegraph
Reported: 2006-04-05 10:32 EDT by Michael Matthews
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-06-30 09:36:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/etc/sysconfig/hwconf (8.25 KB, application/octet-stream)
2006-06-15 04:35 EDT, Ed
no flags Details

  None (edit)
Description Michael Matthews 2006-04-05 10:32:48 EDT
Description of problem:

sound "card" = a physical device such as an Audigy or a pair of USB headphones

When multiple sound "cards" are present in the system, system-config-soundcard
ignores the USB ones. Previously - that is, in FC4 - system-config-soundcard
would load a tab view of all sound "cards" and also provide an option to select
the primary sound "card." But in FC5 only the non-USB devices are present unless
the USB device is the _only_ detected sound "card."

Version-Release number of selected component (if applicable):


How reproducible:

simple, consistent

Steps to Reproduce:
1. Install a physical sound device.
2. Install Fedora Core 5 and boot into it.
3. Plug-in a USB audio device.
4. Run system-config-soundcard.
Actual results:

system-config-soundcard ignores USB audio devices unless they are the only ones
present in the system.

Expected results:

system-config-soundcard should present a tab view listing all cards including
the USB audio devices.

Additional info:

My post to the Fedora mailing list:


Similar posts on fedoraforum.org:


Apparently, this problem might be a larger problem that just happens to manifest
itself when USB audio devices are present. See this thread:

Comment 1 Ed 2006-04-20 02:53:02 EDT
I have an identical problem using USB speakers on a 32-bit Athlon system. The
volume control lets me select them as an output device but soundcard detection
only shows the primary soundcard.
Comment 2 Andrew Alm 2006-06-04 22:19:35 EDT
Just to dig a little deeper into this issue, I installed FC5 and disabled my
on-board audio and I still get this issue. My USB headset, even when the only
device doesnt seem to be detected, though alsamixer finds it ok and volume
control does.

My USB Headset is a plantronics (using snd-usb-audio no doubt).
Comment 3 Andrew Alm 2006-06-04 22:51:06 EDT
Hmm browsing the source it looks like it may be a kudzu issue with kudzu.probe()
and usb audio as the source to system-config-soundcard looks ok.
Comment 4 Martin Stransky 2006-06-05 10:38:01 EDT
I just work on these USB issues...
Comment 5 Ed 2006-06-14 06:37:44 EDT
Please could someone show some interest in this bug. It's a major irritation to
... well me really.

Another point to back up Andrew Alms comment, though equally I may misunderstand

in /etc/sysconfig/hwconf which is produced by kudzu my usb audio device has two
entries, one with a class of AUDIO, one with class of OTHER. Only the entry with
a class of OTHER has a driver snd-usb-audio associated with it. My emu10k1
soundcard has only one entry, there is a driver associated with the AUDIO entry
but there is no 'OTHER' entry

/usr/share/system-config-soundcard/soundcardBackend.py only searches for USB
devices with a class of AUDIO, though there is one of these it has no driver.
Comment 6 Ed 2006-06-14 06:44:14 EDT
Just to confirm by making this change to soundcardBackend.py my usb speakers
work again. May not be the right change but confirms it is a configuration problem

<         list = kudzu.probe(kudzu.CLASS_AUDIO, kudzu.BUS_USB, kudzu.PROBE_ALL)
>         list = kudzu.probe(kudzu.CLASS_OTHER, kudzu.BUS_USB, kudzu.PROBE_ALL)
Comment 7 Andrew Alm 2006-06-14 21:00:10 EDT
I don't think that would work to well to be honest.  I was kind of playing with
the Kudzu source and couldn't get a patch working, though I am thinking its a
problem around line 104 of usb.c in kudzu cvs (usbToKudzu).  It seems like if
the usbclass equals 1, it should return CLASS_OTHER instead of checking the
subclass.  (I can't find any information on audio subclasses).  Ed, I can
probally figure this out if you can look in
/sys/bus/usb/devices/<device>/bDeviceClass and
/sys/bus/usb/devices/<device>/bDeviceSubClass i might be able to get a better
idea of what these values are supposed to mean.
Comment 8 Ed 2006-06-15 04:35:46 EDT
Created attachment 130960 [details]

hwconf contains details of the undetected usb speakers (C-media device)
Comment 9 Ed 2006-06-15 04:38:02 EDT
Comment on attachment 130960 [details]

Sorry to seem dim but couldn't understand what was wanted. here is hwconf
Comment 10 Andrew Alm 2006-06-16 11:51:25 EDT
I think this is a kudzu issue, I will work on a patch and open a bug report
there. To me soundcardBackend.py is doing the right thing, kudzu is not.
Comment 11 Martin Stransky 2006-06-30 09:36:49 EDT
you can check the new s-c-s, select the "System" tab, choose /proc or HAL
detection method a configure your USB card...
Comment 12 Ed 2006-07-03 07:46:01 EDT
Errm, excuse me for being a bit dim, but how do I check the new
system-configure-soundcard? if that's what s-c-s meant
Comment 13 Ed 2006-08-01 06:18:21 EDT
Having realised the new version is likely to be found in rawhide I downloaded a
long list of RPMs but discovered there is a dependency on rtld(GNU_HASH) which
appears to be in a new version of glibc which is in rawhide.

I am unable to risk destabilising my system by updating glibc because I cannot
predict the consequential effect on other packages which might depend on it.

I take it this means that USB audio is (for me) broken until FC5 receives a
glibc update. I will as a workaround use my fix from comment 6.

Note You need to log in before you can comment on or make changes to this bug.