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
