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. In that sense, it might make sense to extend the proc entry of the rawmidi status output, too. > > 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. Takashi
