On Tue, 16 Feb 2016 19:21:37 +0100, Martin Koegler wrote: > > 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. Yeah, there is a difference, of course. But the identifying by the name string suffices? In other words, how would user-space identify the client at best? Passing another attribute to client_info like port type? > > > > 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. Which "device index" do you mean? The index passed at created snd_seq_create_kerne_client()? > 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]. If you mean about the client index offset, then usually they are fixed by each driver. And even the client id number is fixed (up to 4 clients per card): client = 16 + card * 4 + index. So, in most case, the card number can be calculated even without the new information. But, this is rather heuristic, and a clear mapping would be better, of course. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
