[alsa-devel] [PATCH] Provide card number / PID via sequencer client info
Martin Koegler
martin.koegler at chello.at
Tue Feb 16 19:21:37 CET 2016
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
More information about the Alsa-devel
mailing list