[alsa-devel] Device assignment and hotplug

[Takashi Iwai]

At Wed, 5 Sep 2007 20:41:00 +0200,
Krzysztof Helt wrote:
> 
> On Wed, 05 Sep 2007 19:08:45 +0200
> Takashi Iwai <tiwai at suse.de> wrote:
> 
> > Hi,
> > 
> > the recent Linux systems use the auto-probing at boot via udev, and
> > this often screws up the order of device loading, which results in the
> > inconsistent device appearance.  A typical case is that you have a PCI
> > onboard and a USB audio device.  Sometimes the USB appears as the
> > first device while sometimes (most times) PCI appears as the first.
> > 
> > So far, for fixing this order, we use index module option.  That is,
> > add the following to module config:
> > 
> > 	options snd-onboard index=0
> > 	options snd-usb-audio index=1
> > 
> 
> I would rather try to contact udev guys how to solve this. This problem
> is not limited to sound cards. They have solution for hard drives already
> as it hit them first and could even lead to non-bootable system (sda
> swapped with sdb then e.g. /usr partition could not be mounted).
> 
> A general solution would be to use some kind of device locator (e.g. bus:device_id).
> For PCI devices the pci id could be used. For the USB devices, the device id reported
> by lsusb or something id string from the device (like for disks now - they can use disk
> number reported by disk).
> 
> Even, if the problem is solved for USB devices only, it will probably make life much easier
> as the PCI bus is probably always scanned in the same order.
> 
> The same may apply to graphics cards, modems, network cards, etc. A general
> solution (like bus:device_id) would solve it for the most if not all of them.

Well, I've talked about this with udev guys some times.
Actually, the problem isn't about persistent device names.  The
problem does NOT exist if all apps do right -- namely, use ALSA API
and open with the ID string instead of a number.  But, the OSS apps
don't handle persistent device names, and ALSA apps tend to access via
the card number.  These are the problems. (Also we have some code in
alsa-lib assuming the number schemes, but it can be relatively easily
fixed.)

So, we need either to fix all sound apps or to fix the order of
devices in some way.  Obviously, fixing all apps is not a solution
right now (and we can't for binary-only ones).

One way to fix the device order is the index option, and another is
more complex udev rules.  The index option is the way to fix the order
of devices at driver loading time while the latter, udev way, is to
remap the existing devices to certain "traditional" device files.
In either way, one would need a system-wide configuration: a module
option or a udev rules file.

Note that these two don't conflict at all.  The index option had been
introduced far before udev was invented.  That's why there is no
complex remapping udev rules for the sound, so far.  Thus, we can
implement and improve both at the same time.

My suggestion here is just an improvement for the first one.  We can
introduce a remapping rule in udev at the same time.  Eventually
we'll be able to fix all in udev, then get rid of index stuff in
future.  But, udev remapping is still a longer way to go than my
patch.


> If it is not solvable by udev guys, then you can try doing it in alsa the way I mentioned
> so you can set in the config file which device id (USB serial number or bus:device_id)
> correspond to each sound device.

Yes, it's a possible solution, but it would need more codes, and above
all, it would be more difficult to add entries manually.  The beauty
of this hack is its simpleness.


> In your solution, it is a change of index to some kind of locator.

Yes, it's so.  Merging scattered index options to a single location,
so that you can manage easilly.  Nothing more than that.


Takashi