Comment 24 for bug 8050

It should be pointed out that this problem afflicts OSS drivers as well
as ALSA drivers. I am inclined not to bother fixing the problem for OSS
drivers unless the solution we find for ALSA happens to extend easily to
the OSS case.

Matt Zimmerman wrote:
> Another decision that needs to be made is how to name the devices.

For alsa devices I currently have:

/dev/snd/
    controlC0
    midiC0D0
    pcmC0D0c
    pcmC0D0p
    timer

We could make this:

/dev/snd/card.<some_id>/
    control
    midiD0
    pcmD0c
    pcmD0p
    timer
/dev/snd/card.<another_id>/
    control
    midiD0
    pcmD0c
    pcmD0p
    timer
/dev/snd/
    card0 -> card.<some_id>
    card1 -> card.<another_id>
    controlC0 -> card0/control
    ...

The mapping from card* to card.* would reflect a fixed order of priority among
sound card models. This would provide the desired stability across reboots.
Applications needing to address a particular sound card could use the devices
in /dev/snd/card.<id>/. An application that just wanted to open the "primary"
sound card would use /dev/snd/pcmC0D0p as before.

The "id" is the ALSA I.D. Sound card modules can be loaded with an "id" option.
E.g., normally I see this in /proc/asound/cards:

    0 [CS46xx ]: CS46xx - Sound Fusion CS46xx
                     Sound Fusion CS46xx at 0x50100000/0x50000000, irq 11

but if i put this line in /etc/modprobe.d/sound:

    options snd-cs46xx id=foofoo

I see this in /proc/asound/cards:

    0 [foofoo ]: CS46xx - Sound Fusion CS46xx
                     Sound Fusion CS46xx at 0x50100000/0x50000000, irq 11

I don't know exactly what other effects the id has. For one thing,
mixer settings are stored under the name "state.<id>" in
/var/lib/alsa/asound.state.