s to use, as well as > providing a uniform device interface (i.e pcmX). > - The device driver (e.g snd_uaudio(4), snd_hda(4), ...) layer, which is > responsible for actually communicating with the sound card. > > You could visualize it as follows: > > some usb card -> uaudio0 -> pcm0 > some other usb card -> uaudio1 -> pcm1 > some intel card -> hdaa0 -> pcm2 > > > > > [...] > > > > I can see devd looking to match uaudio0 and pcm2 devices to several > > names it knows (probably from other devd confs?), but it doesn’t seem > > to match my attempt. Let alone that it got around to attempting to > > parse my sh tidbit. > > So in your case, "pcm2" is a generic name given to the device by > sound(4) and "uaudio0" is the name of the driver this device is using, > but the actual device node is /dev/dsp2. > > What I think is confusing is that sound(4) names devices as "pcm", but > creates the nodes as "dsp"... Maybe I should propose a patch to get rid > of this scheme, and simply name them everywhere as either "pcm", "dsp", > or something else like "snd". > > Christos Maybe what newbies want would be: *Currently active audio device is always seen as exactly the same, without device number or something. *Basically newly attached "physical" device is always preferred. For example: If a USB audio is plugged and powered on, it is preferred. After that, if a headphone is plugged into the connector, the headphone is automagically selected and other outputs are automatically muted. After that, if optical SPDIF is connected, mute headphone and route output to SPDIF. When the SPDIF plug is disconnected, automatically fall back to headphone. If the headphone is plugged out before SPDIF, fall back to USB, and more, if USB is not available ATM, fall back to PC speaker. Cannot point into specific posts, but I see screams like "Hey, I cannot hear audio output from headphone. How can I do it?!" in Forums. And currently the answers should be quite specific with the questioner's environment (including hardware quirks) and hard to answer. Would be complexed to implement (automate). But parts of those is possible by virtual_oss, by letting it create /dev/dsp, without number. And ports supporting base OSS to default to unnumbered device. My basic assumption is that virtual_oss would be worth incorporated in base at some time in the future. Regards. -- Tomoaki AOKI