On Tue, Feb 16, 2016 at 10:27:20AM +0100, Takashi Iwai wrote: > On Tue, 16 Feb 2016 09:59:37 +0100, > > >>>> Aren't they currently ports? > > >>>> seq_midi.c creates just one sequencer device per card number. > > >>> > > >>> Look at cards with synth support, e.g. emu10k1 or OPL3/OPL4. > > > > Or snd-virmidi. > > > > >> Should I export the client_index parameter of snd_seq_create_kernel_client too? > > > > > > Well, I'd rather ask what are the requirements -- in wide ranges. > > > > The original requirement was just the ability to get the card name. > > Yep. And it's the assumption of only rawmidi, I suppose. How would > it differentiate from synth? My users are using a few identical USB MIDI keyboards [or USB MIDI interfaces] and I need to recognize the devices even after reboot. => I want a stable, unique (composite) device ID for kernel sequencer clients+ports. My current ID is: client name, sysfs-path and port number. The sound card number allows to find the device in sysfs and determine the used USB port as stable identifier. I hope, that the registration order for the ports of one USB MIDI device [or sound card] will always be the same. see my prototype: https://build.opensuse.org/package/view_file/home:e9925248:branches:openSUSE:Leap:42.1:Update/grandorgue/0001-Add-support-for-unique-device-IDs.patch?expand=1 OPL3/4 + emuXXX synth register with a different name, so they should be distinct. > > > And, as mentioned, some cards provide indeed multiple clients. How do > > > you identify which client is for what? So far, it's identified only > > > from the name string and the type bits of each port. Isn't it enough? > > > If not, what have to be provided? > > > > This patch is about the card. If we really need a method to identify > > the device, we can still add it later -- this patch does not obstruct > > such an extension. > > Sure, it won't conflict. But, the question is (back to square) > whether it's enough. > > If we know that we shall change the API again, it's better to consider > the design well from the beginning. A short-living API version bump > is the thing we should avoid as much as possible. It's nothing but a > needless stress for maintainers :) > > That said, I'm not particularly against the currently proposed change. > My only concern is whether we need any further change in (near) > future. +1 I just ask myself, if the device index would provide any useful information. I don't know, how to map it to a anything below the soundcard in sysfs. Is the device ID dymanic? [= Are they depending, if I first load the rawmidi module and then the synth module or the other way around]. Regards, Martin _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
