Red Hat Bugzilla – Bug 188033
system-config-soundcard misses usb audio when multiple cards present
Last modified: 2007-11-30 17:11:29 EST
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):
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.
system-config-soundcard ignores USB audio devices unless they are the only ones
present in the system.
system-config-soundcard should present a tab view listing all cards including
the USB audio devices.
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:
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.
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
My USB Headset is a plantronics (using snd-usb-audio no doubt).
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.
I just work on these USB issues...
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.
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)
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>/bDeviceSubClass i might be able to get a better
idea of what these values are supposed to mean.
Created attachment 130960 [details]
hwconf contains details of the undetected usb speakers (C-media device)
Comment on attachment 130960 [details]
Sorry to seem dim but couldn't understand what was wanted. here is hwconf
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.
you can check the new s-c-s, select the "System" tab, choose /proc or HAL
detection method a configure your USB card...
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
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.