Adding new (old) SNDRV_SEQ_PORT_TYPE_MIDI_* defines

Adding new (old) SNDRV_SEQ_PORT_TYPE_MIDI_* defines

[Adam Goode]

Hi,

I found the /* TODO: read port flags from descriptors */ in
sound/usb/midi.c and was thinking about what to do to implement this.

The first thing to do would be to ensure that all the flags from the
element descriptors in the USB MIDI standard are available for returning
from snd_seq_port_info_get_type.

USB MIDI (see page 23):
http://www.usb.org/developers/docs/devclass_docs/midi10.pdf

I propose adding these flags to ALSA:

#define SNDRV_SEQ_PORT_TYPE_MIDI_CLOCK  (1<<7)  /* MIDI CLOCK compatible
device */
#define SNDRV_SEQ_PORT_TYPE_MIDI_TIME_CODE (1<<8) /* MTC compatible device
*/
#define SNDRV_SEQ_PORT_TYPE_MIDI_MACHINE_CONTROL (1<<9) /* MMC compatible
device */
#define SNDRV_SEQ_PORT_TYPE_MIDI_EFX    (1<<21) /* Audio effects processor
device */
#define SNDRV_SEQ_PORT_TYPE_MIDI_PATCH_BAY (1<<22) /* MIDI patcher or
router device */
#define SNDRV_SEQ_PORT_TYPE_MIDI_DLS1   (1<<23) /* DownLoadable Sounds
Standard Level 1 compatible device */
#define SNDRV_SEQ_PORT_TYPE_MIDI_DLS2   (1<<24) /* DownLoadable Sounds
Standard Level 2 compatible device */


Thoughts? I can send a couple patches for the kernel and alsa-lib. I don't
think this is a breaking change.


Thanks,

Adam

Re: Adding new (old) SNDRV_SEQ_PORT_TYPE_MIDI_* defines

[Takashi Iwai]

At Thu, 12 Mar 2015 20:36:19 -0400,
Adam Goode wrote:
> 
> Hi,
> 
> I found the /* TODO: read port flags from descriptors */ in
> sound/usb/midi.c and was thinking about what to do to implement this.
> 
> The first thing to do would be to ensure that all the flags from the
> element descriptors in the USB MIDI standard are available for returning
> from snd_seq_port_info_get_type.
> 
> USB MIDI (see page 23):
> http://www.usb.org/developers/docs/devclass_docs/midi10.pdf
> 
> I propose adding these flags to ALSA:
> 
> #define SNDRV_SEQ_PORT_TYPE_MIDI_CLOCK  (1<<7)  /* MIDI CLOCK compatible
> device */
> #define SNDRV_SEQ_PORT_TYPE_MIDI_TIME_CODE (1<<8) /* MTC compatible device
> */
> #define SNDRV_SEQ_PORT_TYPE_MIDI_MACHINE_CONTROL (1<<9) /* MMC compatible
> device */
> #define SNDRV_SEQ_PORT_TYPE_MIDI_EFX    (1<<21) /* Audio effects processor
> device */
> #define SNDRV_SEQ_PORT_TYPE_MIDI_PATCH_BAY (1<<22) /* MIDI patcher or
> router device */
> #define SNDRV_SEQ_PORT_TYPE_MIDI_DLS1   (1<<23) /* DownLoadable Sounds
> Standard Level 1 compatible device */
> #define SNDRV_SEQ_PORT_TYPE_MIDI_DLS2   (1<<24) /* DownLoadable Sounds
> Standard Level 2 compatible device */
> 
> 
> Thoughts? I can send a couple patches for the kernel and alsa-lib. I don't
> think this is a breaking change.

I'm fine with this extension (as long as it's tested :)


Takashi

Re: Adding new (old) SNDRV_SEQ_PORT_TYPE_MIDI_* defines

[Clemens Ladisch]

Adam Goode wrote:
> I found the /* TODO: read port flags from descriptors */ in
> sound/usb/midi.c and was thinking about what to do to implement this.
>
> The first thing to do would be to ensure that all the flags from the
> element descriptors in the USB MIDI standard are available for returning
> from snd_seq_port_info_get_type.

I don't know of any class-compliant USB MIDI device that actually has
elements and declares them in its descriptors.

Do you have anything that would allow us to test this?

> I propose adding these flags to ALSA:
>
> #define SNDRV_SEQ_PORT_TYPE_MIDI_CLOCK  (1<<7)  /* MIDI CLOCK compatible device */
> #define SNDRV_SEQ_PORT_TYPE_MIDI_TIME_CODE (1<<8) /* MTC compatible device */
> #define SNDRV_SEQ_PORT_TYPE_MIDI_MACHINE_CONTROL (1<<9) /* MMC compatible device */
> #define SNDRV_SEQ_PORT_TYPE_MIDI_EFX    (1<<21) /* Audio effects processor device */
> #define SNDRV_SEQ_PORT_TYPE_MIDI_PATCH_BAY (1<<22) /* MIDI patcher or router device */
> #define SNDRV_SEQ_PORT_TYPE_MIDI_DLS1   (1<<23) /* DownLoadable Sounds Standard Level 1 compatible device */
> #define SNDRV_SEQ_PORT_TYPE_MIDI_DLS2   (1<<24) /* DownLoadable Sounds Standard Level 2 compatible device */
>
> Thoughts? I can send a couple patches for the kernel and alsa-lib. I don't
> think this is a breaking change.

The first three flags might be useful.  Their problem is that software
cannot rely on them being set for all ports connected to devices that
support these features, but the other PORT_TYPE_MIDI flags have the same
problem.

I don't see any useful application for the other four flags.  I think
the driver should just ignore them.


Regards,
Clemens

Re: Adding new (old) SNDRV_SEQ_PORT_TYPE_MIDI_* defines

[Adam Goode]

On Fri, Mar 13, 2015 at 4:07 AM, Clemens Ladisch <clemens@ladisch.de> wrote:

> Adam Goode wrote:
> > I found the /* TODO: read port flags from descriptors */ in
> > sound/usb/midi.c and was thinking about what to do to implement this.
> >
> > The first thing to do would be to ensure that all the flags from the
> > element descriptors in the USB MIDI standard are available for returning
> > from snd_seq_port_info_get_type.
>
> I don't know of any class-compliant USB MIDI device that actually has
> elements and declares them in its descriptors.
>
> Do you have anything that would allow us to test this?
>
> > I propose adding these flags to ALSA:
> >
> > #define SNDRV_SEQ_PORT_TYPE_MIDI_CLOCK  (1<<7)  /* MIDI CLOCK compatible
> device */
> > #define SNDRV_SEQ_PORT_TYPE_MIDI_TIME_CODE (1<<8) /* MTC compatible
> device */
> > #define SNDRV_SEQ_PORT_TYPE_MIDI_MACHINE_CONTROL (1<<9) /* MMC
> compatible device */
> > #define SNDRV_SEQ_PORT_TYPE_MIDI_EFX    (1<<21) /* Audio effects
> processor device */
> > #define SNDRV_SEQ_PORT_TYPE_MIDI_PATCH_BAY (1<<22) /* MIDI patcher or
> router device */
> > #define SNDRV_SEQ_PORT_TYPE_MIDI_DLS1   (1<<23) /* DownLoadable Sounds
> Standard Level 1 compatible device */
> > #define SNDRV_SEQ_PORT_TYPE_MIDI_DLS2   (1<<24) /* DownLoadable Sounds
> Standard Level 2 compatible device */
> >
> > Thoughts? I can send a couple patches for the kernel and alsa-lib. I
> don't
> > think this is a breaking change.
>
> The first three flags might be useful.  Their problem is that software
> cannot rely on them being set for all ports connected to devices that
> support these features, but the other PORT_TYPE_MIDI flags have the same
> problem.
>
> I don't see any useful application for the other four flags.  I think
> the driver should just ignore them.
>

Hmm, it would be nice to be able to expose all the descriptors the hardware
is providing. But I do worry about polluting this bitmap with all these
flags. I'll have to think about this a little more.


Thanks,

Adam