From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.0.2 (X11; Linux i686; U;) Gecko/20011226 Description of problem: I have a PCI sound card (that doesn't need DMA buffers pre-allocated) and a USB camera that has a microphone built in to it. After booting, my sound card is mapped to /dev/dsp1, and the USB microphone is mapped to /dev/dsp. Not having an output device on /dev/dsp wreaks plenty of havoc with most programs that are (unfortunately) expecting /dev/dsp to be the device that plays sounds. Removing the USB device and rebooting corrects the issue. P.S. This USB camera's video isn't supported by the current Red-Hat kernel release, although it works OK for me under a 2.4.17 kernel (Logitech QuickCam 3000 Pro). However, this sort of problem would occur on any of the supported USB devices that have a microphone (and use the audio class). It should actually occur on a supported RedHat kernel as well, since the audio class is supported separately from the video function. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Install a sound card in a PC, and attach a USB device that implemements the audio class. 2. Boot the PC. Actual Results: Notice that the USB audio device gets mapped to /dev/dsp, and that the regular sound card gets mapped to /dev/dsp1. On top of that, the information in /etc/modules.conf is now wrong, because it isn't updated to accound for the new sound slot for the sound card. Expected Results: The device that supports audio playback should be mapped to /dev/dsp. Other devices should be added thereafter. At least, that's my best guess. I'm sure there's no perfect way to solve this, although your average Windows box seems to do the intuitive thing most of the time. Additional info: I'm sure this is a can of worms, and that it's really a small case of a bigger problem. I got the desired effect by patching /etc/rc.sysinit to always check for and load a sound card before starting the usb bus. There are probably problems with that approach as well.
Created attachment 93173 [details] hwconf on my system, made at about first or second boot time I'm still seeing this on Severn. I'm going to start looking at this, but I'm awfully new to Linux devices, so any hints would be appreciated. Anyway, here's the /etc/sysconfig/hwconf file on my system. It was made right after firstboot last touched /etc/sysconfig/firstboot. -rw-r--r-- 1 root root 17 Jul 26 14:23 /etc/sysconfig/firstboot -rw-r--r-- 1 root root 6776 Jul 26 14:22 /etc/sysconfig/hwconf -rw-r--r-- 1 root root 1412 Jul 26 13:48 /root/anaconda-ks.cfg Strangely, firstboot didn't actually finish properly on my first boot (Bug #100906), so I get the feeling that these modtimes are from the second boot. This is probably tangential, but I'll record it in case it isn't. At this point, my USB camera isn't plugged in, so hwconf doesn't see it. It does see plenty of other USB devices, though, including the USB devices on the hub. When I plug the USB camera in a little later (on the third boot of the PC), its information doesn't get added to /etc/sysconfig/hwconf. Running kudzu from the command line detects the device. I'm thinking that if kudzu can detect the camera and add its information to /etc/sysconfig/hwconf, there's a chance that something can be done about the camera's microphone claiming /dev/dsp. Is that a proper function for kudzu, or should that be handled elsewhere?
Created attachment 93174 [details] Results of running kudzu after boot, manually So, while the system was powered off, I attached the camera and powered up, and found, as noted above, that /etc/sysconfig/hwconf hadn't been modified. Once I could log in, I ran 'kudzu -s -p > hwconf-postboot'. Results are attached. The only real difference from the first file is that the videocamera was added. I'm not sure why kudzu didn't handle this during the boot process, since it should be running: chkconfig --list kudzu kudzu 0:off 1:off 2:off 3:on 4:on 5:on 6:off I'll try a few more reboots to make sure I'm not smoking something.
Another reboot had no effect. However, after rebooting and logging in, running 'kudzu -q' manually results in an update to /etc/sysconfig/hwconf, containing the proper lines for the camera (file is identical to attachment 93174 [details] in this case), and proper updates for sound-slot-1 to /etc/modules.conf. Maybe kudzu wasn't completing during the boot process? I don't see anything in /var/log/mesassages or /var/log/boot.log to indicate that /usr/sbin/kudzu returned for reason of a timeout. In fact, looking at the log files, I don't see any mention of kudzu in "boot.log" until after I had manually ran kudzu by hand (outside the confines of the initscript): /var/log/messages:Jul 26 21:38:06 creaky kudzu: aliased sound-slot-1 as pwc After another reboot, I see the first signs of kudzu completing in boot.log and the messages log - prior to that point there are no entries at all for kudzu in either of those files: /var/log/boot.log:Jul 26 21:59:15 creaky kudzu: succeeded /var/log/messages:Jul 26 21:59:15 creaky kudzu: succeeded /var/log/boot.log:Jul 26 21:59:16 creaky kudzu: Updating /etc/fstab succeeded /var/log/messages:Jul 26 21:59:16 creaky kudzu: Updating /etc/fstab succeeded This is starting to look like 2 problems - one under which kudzu and the associated initscript don't run to completion in the boot process until after I manually run kudzu after logging in, and another which is the longstanding problem with the audio on the camera assigned to the wrong device. I'm learning something, but not getting very close to the original problem quite yet. Any ideas on what I can look for? I imagine I can reproduce this by replace by current /etc/sysconfig/hwconf and /etc/modules.conf with older revisions if necessary.
There's a simple solution for this I have lying around somewhere needing implementation. I just have to remember what it is. :)
Simple sounds good. I gave it some thought, but didn't arrive at anything satisfactory. Here's what I came up with, on the chance that it jogs your memory: The simplest thing I can think of would be to have a "hotplug fixup" phase in the boot process that takes stock of the devices in the system, and renames the device files based on device capabilities. So if it determines that the devices at /dev/dsp and /dev/dsp1 really ought to be swapped, it can rename them. If this is all done before the system begins running in multi-user mode, and you make sure that the initscripts aren't using any of those devices, you could avoid race conditions. The most correct thing I can think of is to modify the kernel code that assigns minor numbers to sound devices to assign not on a first-come, first-serve basis. Instead, the minor numbers for /dev/dsp0, /dev/mixer0, (any others?) could be reserved for devices that have both input and output capabilities. Maybe that's too much policy for the kernel, so maybe the sound system could ask a user-space daemon or file for guidance. I don't really like either of these. The first is too much a hack, the second is too invasive, and to do it right probably means making some service that could be used by devices of all types, which is even more invasive - too invasive by far for the amount of thought I've given it...
This is solved in FC3; built-in cards are enumerated before USB.