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

[Takashi Iwai]

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