Support for getting "manufacturer" from snd_seq_client_info and/or snd_ctl_card_info

Support for getting "manufacturer" from snd_seq_client_info and/or snd_ctl_card_info

[Adam Goode]

Hi,

I am doing a bit of work on the Alsa Web MIDI implementation in Chrome:
https://code.google.com/p/chromium/issues/detail?id=344410

Web MIDI likes to know the "manufacturer" field as part of its API:
http://webaudio.github.io/web-midi-api/#attributes-3

The current implementation in Chrome uses rawmidi, and then tries to parse
out the manufacturer from the longname of the card. This works reasonably
well, but is brittle and results in a lot of code.

I am working on a seq implementation for Chrome, to replace the rawmidi
implementation. I can retain the manufacturer extraction hack on the card,
but seq requires yet another hack to guess the card for a particular seq
client.

Any suggestions on how to extract the manufacturer more easily? The best
solution would be to add a manufacturer (or vendor) field to the
snd_seq_client_info ioctl struct. This would likely require a new ioctl,
since there is only 64 bytes reserved in the current struct. I am guessing
this is not too likely to be accepted. (I would want to also add the same
manufacturer field to the snd_ctl_card_info.)

The next best solution would be to add a card field to snd_seq_client_info,
which could be optionally populated with the card that is associated to the
client.

A completely different solution would be to add all this info to sysfs
which is easier to extend dynamically and won't require any ioctl changes
at all. (I kind of like this solution the best, but it would be a change
from the ioctl-based mechanisms done so far.)

Ultimately, if I am stuck guessing and parsing, that will work as long as
the underlying implementation doesn't change. But I would rather have a
more reliable solution going forward.

Any thoughts?


Thanks,

Adam Goode

Re: Support for getting "manufacturer" from snd_seq_client_info and/or snd_ctl_card_info

[Clemens Ladisch]

Adam Goode wrote:
> I am doing a bit of work on the Alsa Web MIDI implementation in Chrome:
> https://code.google.com/p/chromium/issues/detail?id=344410
>
> Web MIDI likes to know the "manufacturer" field as part of its API:
> http://webaudio.github.io/web-midi-api/#attributes-3
>
> The current implementation in Chrome uses rawmidi, and then tries to parse
> out the manufacturer from the longname of the card. This works reasonably
> well, but is brittle and results in a lot of code.
>
> I am working on a seq implementation for Chrome, to replace the rawmidi
> implementation. I can retain the manufacturer extraction hack on the card,
> but seq requires yet another hack to guess the card for a particular seq
> client.

Did you test this with anything besides USB devices?

And software clients do not have a card.

> Any suggestions on how to extract the manufacturer more easily? The best
> solution would be to add a manufacturer (or vendor) field to the
> snd_seq_client_info ioctl struct.

Old clients would not know to set this field.

The Core MIDI documentation says:
| kMIDIPropertyManufacturer
|   Drivers *should* set this property on their devices.
|   Creators of virtual endpoints *may* set this property on their endpoints.

So what happens on OS X if this is not set?

> A completely different solution would be to add all this info to sysfs

USB devices already have this information in sysfs.


How about an easy solution: just use "Linux".
(IIRC this is what Microsoft's MME/WDM bridge driver does.)


Regards,
Clemens

Re: Support for getting "manufacturer" from snd_seq_client_info and/or snd_ctl_card_info

[Adam Goode]

tl;dr Is anyone against me exposing all the stuff currently in /proc/asound
via sysfs files? And then can I add more stuff?


On Sun, May 11, 2014 at 12:50 AM, Clemens Ladisch <clemens@ladisch.de>wrote:

> Adam Goode wrote:
> > I am working on a seq implementation for Chrome, to replace the rawmidi
> > implementation. I can retain the manufacturer extraction hack on the
> card,
> > but seq requires yet another hack to guess the card for a particular seq
> > client.
>
> Did you test this with anything besides USB devices?
>
>
No, this heuristic only works for USB devices.


> And software clients do not have a card.
>
>
That's fine. The manufacturer field is optional when exposed to Web MIDI
clients. But it would be great if we could expose the information when it
is already present in the kernel.



> > Any suggestions on how to extract the manufacturer more easily? The best
> > solution would be to add a manufacturer (or vendor) field to the
> > snd_seq_client_info ioctl struct.
>
> Old clients would not know to set this field.
>
>
That's fine, I am not worried about type=user clients. In most cases there
isn't really a useful manufacturer there.



> The Core MIDI documentation says:
> | kMIDIPropertyManufacturer
> |   Drivers *should* set this property on their devices.
> |   Creators of virtual endpoints *may* set this property on their
> endpoints.
>
> So what happens on OS X if this is not set?
>
>
In this case, we don't expose the manufacturer via Web MIDI.



> > A completely different solution would be to add all this info to sysfs
>
> USB devices already have this information in sysfs.
>
>
This is true. Unfortunately, here are the current steps to get this
information:
1. Given a seq client, attempt to guess the card by making assumptions
about client->card numbering.
2. From the card, attempt to guess the manufacturer by making assumptions
about how longname is constructed. Or, attempt to extract the usb
information from the card info struct and then try to get the info from
/sys (but this gives us only the manufacturer string from usb, not the
quirk vendor name that the usb midi driver knows about).

What I would like to do is make these mappings explicit. Because Alsa is
very ioctl driven, I was thinking the way to do this is through the
existing ioctl API. But since I really just want to expose a lot more
read-only info about the system, perhaps files in /sys would be an
acceptable way to expose this information. At least, I would like to take
the rather detailed information stored in /prod/asound and expose this in a
more sysfs way via /sys, then add more fields and info. Does this sound
reasonable?



>
> How about an easy solution: just use "Linux".
> (IIRC this is what Microsoft's MME/WDM bridge driver does.)
>
>
Yes, that is a solution. :) But I think we can do better here.


>
> Regards,
> Clemens
>

Thanks,
Adam

Re: Support for getting "manufacturer" from snd_seq_client_info and/or snd_ctl_card_info

[Clemens Ladisch]

Adam Goode wrote:
> On Sun, May 11, 2014 at 12:50 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
> > Adam Goode wrote:
> > > I am working on a seq implementation for Chrome, to replace the rawmidi
> > > implementation. I can retain the manufacturer extraction hack on the card,
> > > but seq requires yet another hack to guess the card for a particular seq
> > > client.
> > >
> > > A completely different solution would be to add all this info to sysfs
>
> > USB devices already have this information in sysfs.
>
> This is true. Unfortunately, here are the current steps to get this
> information:
> 1. Given a seq client, attempt to guess the card by making assumptions
>    about client->card numbering.
> 2. From the card, attempt to guess the manufacturer by making
>    assumptions about how longname is constructed. Or, attempt to
>    extract the usb information from the card info struct and then try
>    to get the info from /sys (but this gives us only the manufacturer
>    string from usb, not the quirk vendor name that the usb midi driver
>    knows about).
>
> What I would like to do is make these mappings explicit. Because Alsa
> is very ioctl driven, I was thinking the way to do this is through the
> existing ioctl API. But since I really just want to expose a lot more
> read-only info about the system, perhaps files in /sys would be an
> acceptable way to expose this information.

The ioctl API (and the library API on top of it) already exists.  Why
do you want to introduce another kind of API that cannot be used for
virtual devices?

> At least, I would like to take the rather detailed information stored
> in /prod/asound and expose this in a more sysfs way via /sys, then add
> more fields and info. Does this sound reasonable?

Almost all the information in /proc/asound is already available through
some ioctl, and the missing information can be added easily.


OK, here is my proposal:

1. Add the card number to snd_seq_client_info.  (For kernel drivers;
   user clients might have the PID here while we're at it.)

   (As long as you are interested only in USB devices, this might be all
   you need.)

2. Add the manufacturer name to snd_ctl_card_info.  For USB devices,
   this is almost always known, but most other drivers do not know the
   name of the card manufacturer (as opposed to the chip manufacturer).
   In those cases, the most informative name that a driver could provide
   would be based on a registered ID like "USB:0x1234", "PCI:0x5678", or
   "IEEE:0x9abcde".  (It's possible to look these up in usb.ids, pci.ids,
   and oui.txt, but I'm not sure if it would be a good idea to let
   alsa-lib do this lookup.)


Regards,
Clemens

Re: Support for getting "manufacturer" from snd_seq_client_info and/or snd_ctl_card_info

[Takashi Iwai]

At Tue, 13 May 2014 11:24:40 +0200,
Clemens Ladisch wrote:
> 
> Adam Goode wrote:
> > On Sun, May 11, 2014 at 12:50 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
> > > Adam Goode wrote:
> > > > I am working on a seq implementation for Chrome, to replace the rawmidi
> > > > implementation. I can retain the manufacturer extraction hack on the card,
> > > > but seq requires yet another hack to guess the card for a particular seq
> > > > client.
> > > >
> > > > A completely different solution would be to add all this info to sysfs
> >
> > > USB devices already have this information in sysfs.
> >
> > This is true. Unfortunately, here are the current steps to get this
> > information:
> > 1. Given a seq client, attempt to guess the card by making assumptions
> >    about client->card numbering.
> > 2. From the card, attempt to guess the manufacturer by making
> >    assumptions about how longname is constructed. Or, attempt to
> >    extract the usb information from the card info struct and then try
> >    to get the info from /sys (but this gives us only the manufacturer
> >    string from usb, not the quirk vendor name that the usb midi driver
> >    knows about).
> >
> > What I would like to do is make these mappings explicit. Because Alsa
> > is very ioctl driven, I was thinking the way to do this is through the
> > existing ioctl API. But since I really just want to expose a lot more
> > read-only info about the system, perhaps files in /sys would be an
> > acceptable way to expose this information.
> 
> The ioctl API (and the library API on top of it) already exists.  Why
> do you want to introduce another kind of API that cannot be used for
> virtual devices?
> 
> > At least, I would like to take the rather detailed information stored
> > in /prod/asound and expose this in a more sysfs way via /sys, then add
> > more fields and info. Does this sound reasonable?
> 
> Almost all the information in /proc/asound is already available through
> some ioctl, and the missing information can be added easily.
> 
> 
> OK, here is my proposal:
> 
> 1. Add the card number to snd_seq_client_info.  (For kernel drivers;
>    user clients might have the PID here while we're at it.)
> 
>    (As long as you are interested only in USB devices, this might be all
>    you need.)
> 
> 2. Add the manufacturer name to snd_ctl_card_info.  For USB devices,
>    this is almost always known, but most other drivers do not know the
>    name of the card manufacturer (as opposed to the chip manufacturer).
>    In those cases, the most informative name that a driver could provide
>    would be based on a registered ID like "USB:0x1234", "PCI:0x5678", or
>    "IEEE:0x9abcde".  (It's possible to look these up in usb.ids, pci.ids,
>    and oui.txt, but I'm not sure if it would be a good idea to let
>    alsa-lib do this lookup.)

This sounds good to me.  It's small enough and least impact to the
existing API.

I'm not opposing to creating /sys entries, though.  But, if we do
exposing to /sys, this has to be done properly.  Namely, the question
isn't only about the sequencer stuff but about all entries in /proc.
So, this won't be a quick task, in anyway.


thanks,

Takashi

Re: Support for getting "manufacturer" from snd_seq_client_info and/or snd_ctl_card_info

[Adam Goode]

On Tue, May 13, 2014 at 8:00 AM, Takashi Iwai <tiwai@suse.de> wrote:
>
> At Tue, 13 May 2014 11:24:40 +0200,
> Clemens Ladisch wrote:
> >
> > Adam Goode wrote:
> > > On Sun, May 11, 2014 at 12:50 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
> > > > Adam Goode wrote:
> > > > > I am working on a seq implementation for Chrome, to replace the rawmidi
> > > > > implementation. I can retain the manufacturer extraction hack on the card,
> > > > > but seq requires yet another hack to guess the card for a particular seq
> > > > > client.
> > > > >
> > > > > A completely different solution would be to add all this info to sysfs
> > >
> > > > USB devices already have this information in sysfs.
> > >
> > > This is true. Unfortunately, here are the current steps to get this
> > > information:
> > > 1. Given a seq client, attempt to guess the card by making assumptions
> > >    about client->card numbering.
> > > 2. From the card, attempt to guess the manufacturer by making
> > >    assumptions about how longname is constructed. Or, attempt to
> > >    extract the usb information from the card info struct and then try
> > >    to get the info from /sys (but this gives us only the manufacturer
> > >    string from usb, not the quirk vendor name that the usb midi driver
> > >    knows about).
> > >
> > > What I would like to do is make these mappings explicit. Because Alsa
> > > is very ioctl driven, I was thinking the way to do this is through the
> > > existing ioctl API. But since I really just want to expose a lot more
> > > read-only info about the system, perhaps files in /sys would be an
> > > acceptable way to expose this information.
> >
> > The ioctl API (and the library API on top of it) already exists.  Why
> > do you want to introduce another kind of API that cannot be used for
> > virtual devices?
> >
> > > At least, I would like to take the rather detailed information stored
> > > in /prod/asound and expose this in a more sysfs way via /sys, then add
> > > more fields and info. Does this sound reasonable?
> >
> > Almost all the information in /proc/asound is already available through
> > some ioctl, and the missing information can be added easily.
> >
> >
> > OK, here is my proposal:
> >
> > 1. Add the card number to snd_seq_client_info.  (For kernel drivers;
> >    user clients might have the PID here while we're at it.)
> >
> >    (As long as you are interested only in USB devices, this might be all
> >    you need.)
> >
> > 2. Add the manufacturer name to snd_ctl_card_info.  For USB devices,
> >    this is almost always known, but most other drivers do not know the
> >    name of the card manufacturer (as opposed to the chip manufacturer).
> >    In those cases, the most informative name that a driver could provide
> >    would be based on a registered ID like "USB:0x1234", "PCI:0x5678", or
> >    "IEEE:0x9abcde".  (It's possible to look these up in usb.ids, pci.ids,
> >    and oui.txt, but I'm not sure if it would be a good idea to let
> >    alsa-lib do this lookup.)
>
> This sounds good to me.  It's small enough and least impact to the
> existing API.
>
> I'm not opposing to creating /sys entries, though.  But, if we do
> exposing to /sys, this has to be done properly.  Namely, the question
> isn't only about the sequencer stuff but about all entries in /proc.
> So, this won't be a quick task, in anyway.
>
>

Thanks for spending time on this. I like this proposal very much. I
plan to look at sending some patches in the next week or so for
review.

One question I have for step 2 above: snd_ctl_card_info is full. I
don't see a way of adding to it without introducing a new ioctl
(SNDRV_CTL_IOCTL_CARD_INFO2 + struct snd_ctl_card_info2?)

I am happy to do this, just wanted to make sure it was the right way.
(alsa-lib should hide this change through its accessors I believe.)

Thanks,

Adam

Re: Support for getting "manufacturer" from snd_seq_client_info and/or snd_ctl_card_info

[Takashi Iwai]

At Thu, 15 May 2014 16:47:03 -0700,
Adam Goode wrote:
> 
> On Tue, May 13, 2014 at 8:00 AM, Takashi Iwai <tiwai@suse.de> wrote:
> >
> > At Tue, 13 May 2014 11:24:40 +0200,
> > Clemens Ladisch wrote:
> > >
> > > Adam Goode wrote:
> > > > On Sun, May 11, 2014 at 12:50 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
> > > > > Adam Goode wrote:
> > > > > > I am working on a seq implementation for Chrome, to replace the rawmidi
> > > > > > implementation. I can retain the manufacturer extraction hack on the card,
> > > > > > but seq requires yet another hack to guess the card for a particular seq
> > > > > > client.
> > > > > >
> > > > > > A completely different solution would be to add all this info to sysfs
> > > >
> > > > > USB devices already have this information in sysfs.
> > > >
> > > > This is true. Unfortunately, here are the current steps to get this
> > > > information:
> > > > 1. Given a seq client, attempt to guess the card by making assumptions
> > > >    about client->card numbering.
> > > > 2. From the card, attempt to guess the manufacturer by making
> > > >    assumptions about how longname is constructed. Or, attempt to
> > > >    extract the usb information from the card info struct and then try
> > > >    to get the info from /sys (but this gives us only the manufacturer
> > > >    string from usb, not the quirk vendor name that the usb midi driver
> > > >    knows about).
> > > >
> > > > What I would like to do is make these mappings explicit. Because Alsa
> > > > is very ioctl driven, I was thinking the way to do this is through the
> > > > existing ioctl API. But since I really just want to expose a lot more
> > > > read-only info about the system, perhaps files in /sys would be an
> > > > acceptable way to expose this information.
> > >
> > > The ioctl API (and the library API on top of it) already exists.  Why
> > > do you want to introduce another kind of API that cannot be used for
> > > virtual devices?
> > >
> > > > At least, I would like to take the rather detailed information stored
> > > > in /prod/asound and expose this in a more sysfs way via /sys, then add
> > > > more fields and info. Does this sound reasonable?
> > >
> > > Almost all the information in /proc/asound is already available through
> > > some ioctl, and the missing information can be added easily.
> > >
> > >
> > > OK, here is my proposal:
> > >
> > > 1. Add the card number to snd_seq_client_info.  (For kernel drivers;
> > >    user clients might have the PID here while we're at it.)
> > >
> > >    (As long as you are interested only in USB devices, this might be all
> > >    you need.)
> > >
> > > 2. Add the manufacturer name to snd_ctl_card_info.  For USB devices,
> > >    this is almost always known, but most other drivers do not know the
> > >    name of the card manufacturer (as opposed to the chip manufacturer).
> > >    In those cases, the most informative name that a driver could provide
> > >    would be based on a registered ID like "USB:0x1234", "PCI:0x5678", or
> > >    "IEEE:0x9abcde".  (It's possible to look these up in usb.ids, pci.ids,
> > >    and oui.txt, but I'm not sure if it would be a good idea to let
> > >    alsa-lib do this lookup.)
> >
> > This sounds good to me.  It's small enough and least impact to the
> > existing API.
> >
> > I'm not opposing to creating /sys entries, though.  But, if we do
> > exposing to /sys, this has to be done properly.  Namely, the question
> > isn't only about the sequencer stuff but about all entries in /proc.
> > So, this won't be a quick task, in anyway.
> >
> >
> 
> Thanks for spending time on this. I like this proposal very much. I
> plan to look at sending some patches in the next week or so for
> review.
> 
> One question I have for step 2 above: snd_ctl_card_info is full. I
> don't see a way of adding to it without introducing a new ioctl
> (SNDRV_CTL_IOCTL_CARD_INFO2 + struct snd_ctl_card_info2?)
> 
> I am happy to do this, just wanted to make sure it was the right way.
> (alsa-lib should hide this change through its accessors I believe.)

Some extra IDs have been already added in card.component field.  
It's a string list separated by space letters, and USB-audio adds
vendor and product hex numbers like USB12ab:ab12.  Then user-space app
can fetch more details by itself.


Takashi

Re: Support for getting "manufacturer" from snd_seq_client_info and/or snd_ctl_card_info

[Clemens Ladisch]

Adam Goode wrote:
>> Clemens Ladisch wrote:
>>> 2. Add the manufacturer name to snd_ctl_card_info.  For USB devices,
>>>    this is almost always known, but most other drivers do not know the
>>>    name of the card manufacturer (as opposed to the chip manufacturer).
>>>    In those cases, the most informative name that a driver could provide
>>>    would be based on a registered ID like "USB:0x1234", "PCI:0x5678", or
>>>    "IEEE:0x9abcde".
>
> One question I have for step 2 above: snd_ctl_card_info is full. I
> don't see a way of adding to it without introducing a new ioctl
> (SNDRV_CTL_IOCTL_CARD_INFO2 + struct snd_ctl_card_info2?)

If you really want to avoid adding a new ioctl:  The numerical IDs are
just numbers, for which there is enough space in snd_ctl_card_info.  For
USB devices, the manufacturer name is part of the longname, so you'd
just need offset/length values.

And I'm not sure if it would be a good idea to expose the manufacturer
ID as a string.  Is that value supposed to be shown to the user, or just
some unique ID?


Regards,
Clemens

Re: Support for getting "manufacturer" from snd_seq_client_info and/or snd_ctl_card_info

[Adam Goode]

On Fri, May 16, 2014 at 3:26 AM, Clemens Ladisch <clemens@ladisch.de> wrote:

> Adam Goode wrote:
> >> Clemens Ladisch wrote:
> >>> 2. Add the manufacturer name to snd_ctl_card_info.  For USB devices,
> >>>    this is almost always known, but most other drivers do not know the
> >>>    name of the card manufacturer (as opposed to the chip manufacturer).
> >>>    In those cases, the most informative name that a driver could
> provide
> >>>    would be based on a registered ID like "USB:0x1234", "PCI:0x5678",
> or
> >>>    "IEEE:0x9abcde".
> >
> > One question I have for step 2 above: snd_ctl_card_info is full. I
> > don't see a way of adding to it without introducing a new ioctl
> > (SNDRV_CTL_IOCTL_CARD_INFO2 + struct snd_ctl_card_info2?)
>
> If you really want to avoid adding a new ioctl:  The numerical IDs are
> just numbers, for which there is enough space in snd_ctl_card_info.  For
> USB devices, the manufacturer name is part of the longname, so you'd
> just need offset/length values.
>
> And I'm not sure if it would be a good idea to expose the manufacturer
> ID as a string.  Is that value supposed to be shown to the user, or just
> some unique ID?
>
>
For Web MIDI, we don't actually need the USB ids, but it is good to have
these available. snd_ctl_card_info already has these encoded via the
components field:

$ ./alsa-lib/test/control

Soundcard #1:
  card - 0
  id - 'UX16'
  driver - 'USB-Audio'
  name - 'UX16'
  longname - 'Yamaha UX16 at usb-0000:00:14.0-10, full speed'
  mixername - ''
  components - 'USB0499:1009'
RAWMIDI info, device #0:
  device - 0
  subdevice - 0
  stream - 0
  card - 0
  flags - 0x7
  id - 'USB MIDI'
  name - 'UX16'
  subname - 'UX16 MIDI 1'
  subdevices count - 1
  subdevices avail - 0
 ...

For getting manufacturer, it is an interesting idea to encode the offset
and length for extraction from longname. I have no problem with creating a
new ioctl though, which seems cleaner, if that is acceptable.

The manufacturer string is just a string, to be presented to the user. It
is not a unique/opaque id.



Adam