[alsa-devel] [PATCH] Provide card number / PID via sequencer client info

[Martin Koegler]

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