On Sun, 9 Mar 2008 15:57:16 -0700 "Mark Knecht" &lt;markknecht(a)gmail.com&gt; wrote: I have not tried this but maybe well crafted udev rules could help ? The page http://reactivated.net/writing_udev_rules.html#sysfsmatch gives hints about matching device names to data read from sysfs. Reading this doc, it looks like you might find info that uniquely identify each of your cards using the command "udevinfo -a -p $(udevinfo -q path -n /dev/snd/<yourdevice>)" and craft you local rules from there. This might be a question worth asking on alsa-users too. HTH -- David

On Sun Mar 09, 2008 at 07:24:00PM -0700, Mark Knecht wrote: there is, alias snd-slot and snd-card stuff in modprobe conf in /etc (/etc/modules.d/alsa here). im not sure if it works if all the cards are using the same driver keeps my internal on hw:1 so an Indigo is alwyas default anwyays..

On Mon, 2008-03-10 at 11:22 +0100, Arnold Krille wrote: I don't think that this is what Mark was asking for. The problem he is facing is that if you have, say, 3 RME HDSP's, the information used to identify them to ALSA (at least) is identical in every case. It is therefore tricky to ensure that what you consider to be the "first" card is always hw:0 and so forth. The usual ALSA mechanism relies on PCI id and other stuff that, IIRC, is not going to distinguish between 3 identical cards. He does *not* want to run the 3 cards as one, and if he does, he knows he has to keep them in sync. I don't know of a solution to this. I guess that the PCI registers for the cards contain some kind of serial number, but how you can get ALSA to based its snd_index assignments on that, I don't know. --p

On Mon, Mar 10, 2008 at 5:06 AM, Paul Davis &lt;paul(a)linuxaudiosystems.com&gt; wrote: Thanks Paul. Your assessment of my question was correct. In my current system I already keep cards in sync just using ADAT or spdif sync. Personally I probably wouldn't buy any card these days that couldn't respond to some sort of external sync signal as it seems that over time some need for that always comes up. Thanks to Arnold for his information though. Maybe that will help someone else in the future. For example if I have 3 HDSP9652's in a system in a system I could in theory have the ADAT cables from two of the cards going to a mixing desk, the lower half of the desk being card 0 and the upper half being card 1. (Or two desks in parallel.) The 3rd card might be talking to an external rack of signal processors. What is important is that the system not arbitrarily change the 3 groups of connections the next time I boot the system or I find myself mixing inside of a reverb unit and wondering why my mixer sounds dry. In Windows the system seems to read the card's firmware where it finds some unique ID value, possibly just the PCI device and vendor IDs, and then I think possibly builds a table where it records the card type and possibly the PCI slot number or something system specific to make a semi-permanent record of how things are configured. Windows manages to keep this straight even if the interrupts from identical devices are shared. This record is then used to set things up the same way the next time you boot. If the records haven't changed then the assumption is the configuration hasn't either. It seem that Alsa has no capabilities to do that sort of thing but I wanted to check here just to make sure I wasn't selling Alsa short. While it may not be much of a problem for most of us folks would there be any reason not to file an enhancement request with the Alsa devs on this issue? Thanks, Mark

On Mon, Mar 10, 2008 at 6:23 AM, Paul Davis &lt;paul(a)linuxaudiosystems.com&gt; wrote: Yes, that's what I was thinking about. Clearly the PCI Device/Vendor IDs are not sufficient to handle this. And let's not drop out 1394 or other external buses. The issue isn't USB as much as it's an external network of devices that can both be rewired easily and in some cases come and go in strange ways. If you're using an external USB powered hub, for instance, and the power isn't applied for some period of time the system thinks the device is gone when it's just that someone kicked out the wall wart. Making that sort of support of external devices really robust would take some serious thinking. Anyway, I appreciate your inputs and will likely file an enhancement request just to put the idea out there. I suspect a first step could be udev in some hand crafted way. I may explore that idea also. Cheers, Mark

Am Montag, 10. März 2008 schrieb Mark Knecht: The way ffado works, these will all be joined (possibly automatically) in one big device. and each channel on each device is named unique(?) and aliased with system_*. So it should be the same ports in jack everytime you start the setup. But I don't think ffado is currently able to do dynamic add/remove. Can't test it here, not enough fw-devices. ;-) For the real problem: Maybe udev can show some more information (like serial number) for the pci devices? Or maybe it can provide the interrupt. That way unique devices would be possible. Arnold -- visit http://www.arnoldarts.de/ --- Hi, I am a .signature virus. Please copy me into your ~/.signature and send me to all your contacts. After a month or so log in as root and do a "rm -rf /". Or ask your administrator to do so...

Mark Knecht wrote: I suspect what Windows does is record each sound card in its registry (with Windows own unique identifying code for it) *in the order in which they were installed*, then initialize them in that same order (based on the generated unique ID code for the device) when it comes up. Someone with access to a Windows box could spelunk around in the registry and see, I suppose. -- David gnome(a)hawaii.rr.com authenticity, honesty, community

Paul, thank you so much for those links. The first looks like it may solve my issue so long as I (or other parties really) don't rearrange the hookups. all the best, drew On Tuesday 11 March 2008 13:19:24 Adam Sampson wrote: