[UDEV] Persitent ordering of ALSA-devices (was: [gentoo-dev] Re: udev coldplugging and /etc/init.d/modules)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[dropping gentoo-dev since it's OT there, writing to
linux-hotplug-devel, adding alsa-devel, keeping Greg CCed]

*spoiler*
After Gentoo switched to udev-coldplug, my two soundcards get randomly
reordered on reboot. Now I need to write a udev rule to give them a
persistent ordering, but failed to do so until now, partly because i
don't know on what key ALSA orders devices so they become card0 and 1,
hw0 and hw1, partly because this feature of udev is so new.

Greg KH wrote:
> On Sat, Dec 02, 2006 at 12:56:59AM +0100, Jan 'RedBully' Seiffert wrote:
>> OK, then maybe someone knows how to get ALSA-Devices in an persistent
>> ordering with udev-rules?
>> I was unable to find it out by my self, the documentation is a little
>> sparse on this IMHO...
> 
> Just figure out something unique for your sound devices, and create some
> rules like the other persistent rule generators do.  PCI device id
> perhaps?
> 
Writing a matching rule isn't the problem for me, something like:
SUBSYSTEM=="sound", ATTRS{vendor}=="0x1106", ATTRS{device}=="0x3059" §§§
for the on board VIA and:
SUBSYSTEM=="sound", ATTRS{vendor}=="0x1412", ATTRS{device}=="0x1712" §§§
for the Terratec DMX 6Fire.

My problem is at the "§§§". What action should i give these rules?
And as i already wrote, i do *not* need symlinks or the like. I need to
get them in the right oder from the ALSA-POV, hw0 and hw1.
That's also the point where the documentation gets sparse, not on all
the filter and start-external-program things.
(And finally, where have those rules to be placed in the order of udev
rules?)

But maybe i'm off the track and ALSA takes the ordering by /dev-name (or
sysfs name), [controlC|midiC0D|pcmC[\d]D]0 is hw0 and 1 is hw1, but that
is not obvious from /proc/asound, that looks more like i have to
influence card0 and card1, but they are not in /dev or sysfs.

> If you have problems with this, try asking on the linux-hotplug-devel
> mailing list.  The people there can help you out.  It would be good to
> have some rules for sound devices like this, as you aren't the first to
> ask about it.
> 
Looks like, that will be my next stop.
Or even better, i drive by at alsa-devel to ask which magic knob
controls ordering. Hopefully it's not the order in which the modules
call alsa_register_driver or something like that...

>> udev-coldplug bite me with my 2 soundcards (one onboard, one PCI). They
>> are randomly ordered on every reboot. I don't care which /dev/snd/*
>> names they get, ALSA uses them, the times of 'cat /dev/urandom >
>> /dev/dsp' are long gone. I *care* about, which device is snd-card-0 and
>> 1, which is hw0 and hw1, and which device gets bound to 'default'.
> 
> Yeah, I have a box around here like that too :(
> 
hmmm, ok, and did you come to a conclusion how to solve this?
Keep as is/live with it?
Every time when they change order, dive behind your PC to replug your
speaker?
Log in as root and restart /etc/init.d/alsasound? (which is little
uncomfortable for me, because of MusicPlayerDaemon. It gets stoped and
restartet automatically with alsasound, but is busted afterwards. So i
have to stop it by hand before and start it by hand afterwards)

>> Interestingly with the old coldplug the devices always had the same
>> order and (by accident? or /etc/modules.d/alsa?) the right.
> 
> PCI device order is usually quite stable, unless you start to use PCI
> hotplug, or change cards, or update your BIOS.  If you did any of that,
> then it would start to get unpredictable.
> 
No, nothing of that, same BIOS all the time, hotpluging the on board
device would be "very hotpluging" (with a soldering iron), and the
PCI-card is mounted stationary and buried behind the breakout
box-/IDE-/SCSI-ribbon cables, *no* hotplug at all.
Still, on reboot they get randomly ordered by udev-coldplug.
Or it is a "race", i have a SMP system.

Maybe i should take a look at things like "reset ESCD data" (or whatever
it was called) in the BIOS, but i don't see a reason, why it should do this.

> thanks,
> 
> greg k-h
> 
No, i have to thank you as a busy Kernel developer, for taking the time
and looking at my problem. It's an honer for me to get a mail form Greg
KH as a mere user.

Greetings
	Jan

-- 
pod* a;
pott* b;
a = (pod *)b;
a real podcast :-D

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-devel


[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux