[UDEV] Persitent ordering of ALSA-devices (was: [gentoo-dev] Re:

[UDEV] Persitent ordering of ALSA-devices (was: [gentoo-dev] Re:

[Jan 'RedBully' Seiffert]

[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ÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [UDEV] Persitent ordering of ALSA-devices (was: [gentoo-dev] Re:

[Marco d'Itri]

On Dec 02, Jan 'RedBully' Seiffert <redbully@cc.fh-luh.de> wrote:

> My problem is at the "§§§". What action should i give these rules?
I think it's easier to generate index=N entries for /etc/modprobe.d/.
Debian has the same problem, but I have not yet found the time to solve
it.

-- 
ciao,
Marco

-------------------------------------------------------------------------
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ÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [UDEV] Persitent ordering of ALSA-devices (was: [gentoo-dev] Re:

[Darren Salt]

I demand that Jan 'RedBully' Seiffert may or may not have written...

[snip]
> 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...

options snd-foo index=n

If n is in the range 0...31, that index is used. Any device which already has
that index becomes hidden.

If n is negative, it's interpreted as an index mask in which bit b set =
index b is permissible; the lowest unassigned index is used.

[snip]
-- 
| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Output *more* particulate pollutants.      BUFFER AGAINST GLOBAL WARMING.

The future is not what it used to be. (It never was.)

-------------------------------------------------------------------------
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ÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [Alsa-devel] [UDEV] Persitent ordering of ALSA-devices

[Clemens Ladisch]

Jan 'RedBully' Seiffert wrote:
> 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.

ALSA's card ordering mechanism predates udev and isn't compatible with
it.

The ALSA framework has its own internal card list (that is shown in
/proc/asound/cards).  Drivers can be instructed to take a specific card
number with the 'index' option, and this is the only official way of
reordering cards.

It is, in theory, possible to rename the device files, but you have to
be aware that
1) all devices files of one card must be renamed consistently, i.e,
   the card number in the controlC*/hwdepC*D*/rawmidiC*D*/pcmC*D*p/
   pcmC*D*c files (the number after the "C") must be the same for all
   device files belonging to each card; and
2) enumerating cards will no longer work correctly (the card number
   returned by ALSA will still be the number specified with the index
   parameter), i.e., card names/descriptions will be wrong when a
   program tries to show them.


Regards,
Clemens

-------------------------------------------------------------------------
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ÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [Alsa-devel] [UDEV] Persitent ordering of ALSA-devices

[Jan 'RedBully' Seiffert]

Clemens Ladisch wrote:
> Jan 'RedBully' Seiffert wrote:
>> 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.
> 
> ALSA's card ordering mechanism predates udev and isn't compatible with
> it.
> 
*sigh* ;(

> The ALSA framework has its own internal card list (that is shown in
> /proc/asound/cards).  Drivers can be instructed to take a specific card
> number with the 'index' option, and this is the only official way of
> reordering cards.
> 

I want to thank you and Marco for the clarification. After reading
Marcos mail, i slabbed my forehead like: "Ahh, yes, the index option".
Only saw it once on an old SuSE in the conf-files on the PC of my brother.
I now solved the problem for me with:
options snd-ice1712 index=0
options snd-via82xx index=1
in /etc/modules.d/alsa (which then migrates to the automatic generated
/etc/modprobe.conf, on gentoo).
Now, after several reboots, it seems to work, also with udev-coldplug
(which is tricky, because it happens so early, even before module autoload).


> It is, in theory, possible to rename the device files, but you have to
> be aware that
> 1) all devices files of one card must be renamed consistently, i.e,
>    the card number in the controlC*/hwdepC*D*/rawmidiC*D*/pcmC*D*p/
>    pcmC*D*c files (the number after the "C") must be the same for all
>    device files belonging to each card; and
> 2) enumerating cards will no longer work correctly (the card number
>    returned by ALSA will still be the number specified with the index
>    parameter), i.e., card names/descriptions will be wrong when a
>    program tries to show them.
> 
> 

Renaming the device files in a consistent manner shouldn't be the
problem. Sure, the udev-rules would get a little bit longer, but still
possible (or call out to a program which gives the right name back).

But why should i do it, if it does not influence ALSA (the expected
way), only confuses it? And the main target, getting a persistent 'hw0'
etc. and 'default' isn't achieved by it. (especially since my ice1712
needs a lot of magic added (sample rate converter, buffer, dmix), thats
why i want it to be the 'default' device)

I only see one problem for this in the future:
I was able to distinguish the cards by module. But what happens, if
someone has the same card several times (same module)?
Rely on PCI bus ordering? A new PCI quirk for your mainboard to handle a
transparent bridge and then? Multithreaded probing anyone?
(You can strongly object to a feature like this, but it is desirable
from a users POV, like starting [xkg]dm as early as possible, to bring
the user a login screen, while cups and foo and bar still starting in
the background).

Please keep in mind, that Linux is predestinated for such use ;) Drivers
which can handle several instances of the same card (and if not, you can
fix it), ALSA as a fine API, good latency with mostly every card,
continued improvements to the core kernel, directly available to the
user (thanks to stable-API-nonsense.txt *everything* can be
fixed/improved, even if it means a transition for everyone), to raise
(IPC) performance and lower latency in every subsystem (pushed forward
by people with other kind of problems, like > 1k processors (go SGI,
go;), not only "the sound freaks") and RT for the extra fun to build a
cheap recording machine for example.
But i think i don't tell anyone news on this, and i extravagate...

> Regards,
> Clemens
> 
With best wishes and thanks to all who helped,
	Jan

PS: Sorry for any shortcomings in my english, don't had the time to
proof read it 20 times.
-- 
Coffeecup empty - Userpanic!

-------------------------------------------------------------------------
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ÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel