[PATCH v4] sound: rawmidi: Add framing mode

[David Henningsson]

On 2021-04-13 17:27, Takashi Iwai wrote:
> On Mon, 12 Apr 2021 21:32:37 +0200,
> David Henningsson wrote:
>>> One thing I'm considering is how to inform the current framing and the
>>> timestamp mode to user-space.  Currently we have only the ioctl to set
>>> the values but not to inquiry.
>> Yes, this is the same as we do with PCM. There is no ioctl to get
>> current hw/sw params either.
>>
>>> Should we put those new information into the info or the status ioctl?
>> I would prefer neither, because it is not necessary and creates an
>> inconsistency with PCM.
> Well, honestly speaking, ALSA PCM API design is no best one you should
> refer to...  IMO, it should have had the symmetric get function, too.
> I guess it worked without such ioctl because the current PCM status is
> exposed via proc file.  Without a way for inquiry of the current
> status, we may have had trouble for debugging.

Whether or not the ALSA pcm/rawmidi apis should have get functions to 
get its current parameters, seems like a separate discussion, and 
separate patch. It can be done later if there is such a need.

>
> In that sense, it might make sense to extend the proc entry of the
> rawmidi status output, too.
Okay, I can add rows about framing and clock type in the proc file for v5.
>>> If so, it might be also helpful to inform the frame byte size
>>> explicitly there, instead of assuming only a constant.
>> If userspace has verified the kernel protocol version and successfully
>> calledSNDRV_RAWMIDI_IOCTL_PARAMS with the framing
>> byte/bitfield/whatever set, then userspace can be sure that the frames
>> are according to the snd_rawmidi_framing_tstamp struct. Knowing the
>> frame byte size but not knowing the exact format is of no use to
>> userspace anyway, right?
> Sure, if any, the kernel should inform all stuff, the frame type, the
> clock type, and the frame size.  But practically seen, this might be
> not often inquired, if we define the frame struct explicitly as a part
> of user-space API, too.  Then sizeof() already gives the proper size.
> Of course, that depends on how to provide the user-space API.  We may
> provide again an opaque API, too.

The frame struct will be part of the userspace and alsa-lib APIs. I 
intend to follow up with patches to alsa-lib after this patch gets merged.

// David