From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031009 Firebird/0.7+ Description of problem: I have a usb webcam with builtin microphone (no audio output) and a emu10k. The usb driver is loaded first and claims the first audio devices. This includes the /dev/dsp device. The soundcard uses /dev/dsp1. When running redhat-config-soundcard there is nothing but silence since /dev/dsp is used. r-c-s should detect that there is more than one output device. Gnomemeeting does, so it is possible. If more than one device is present it should ask the others. Once the correct device is found (i.e., the user declared s/he heard something) the spwan_options line in /etc/esd.conf should be extended with -d /dev/dspX. Version-Release number of selected component (if applicable): redhat-config-soundcard-1.0.8-2 How reproducible: Always Steps to Reproduce: 1.get web usb cam 2.get some sound card (I guess it doesn't matter which) 3.start system Actual Results: r-c-s and esd don't use correct device. Expected Results: r-c-s should allow testing all devices and adjust esd.conf appropriately. Additional info: I think this is a common problem. I know of at least one other case personally. If there is r-c-s, why doesn't it really try hard to do its job?
Have you had a chance to test with the FC2 trees? The switch to ALSA may improve the situation.
I've had the same problem. The microphone on the USB webcam is loaded as the FIRST sound card. Thus many people complain that they loose sound when they boot with their webcam connected! This shouldn't happen, if the system has more than one sound devices, the user should be asked which one will be used primary. The same problem happens when multiple sound cards are installed. In order to fix the problem with the USB webcam microphone, this has to be added in the modprobe.conf: alias snd-card-0 <your-sound-module> options <your-sound-module> index=0 alias snd-card-1 snd-usb-audio options snd-usb-audio index=1 this will make the usb microphone come second, thus not affect the overall sound output of the system.
*** This bug has been marked as a duplicate of 81843 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.