The frame structure is a bit internal thing for the kernel
data transfer implementation. Introduce snd_rawmidi_tread()
function which is straight for the application usage and hides
the framing data transfers (kernel space API).
The current code implements the read cache and does the merging
of the frame reads with the similar timestamps (opposite
to the kernel data split for big chunks).
If the application wants to use super-duper-lighting-fast reads,
the snd_rawmidi_read() may be used, but the structure must be
defined on it's own, because this mechanism is not preferred
and unsupported.
BugLink: https://github.com/alsa-project/alsa-lib/issues/172
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Optionally, incoming rawmidi bytes can be put inside a frame of type
snd_rawmidi_framing_tstamp_t.
The main current benefit is that can enable in-kernel timestamping of
incoming bytes, and that timestamp is likely to be more precise than
what userspace can offer.
Tstamp type framing requires a kernel >= 5.14 and a buffer size that
is a multiple of sizeof(snd_rawmidi_framing_tstamp_t). It is only
available on input streams.
Signed-off-by: David Henningsson <coding@diwic.se>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Like pcm and rawmidi, each object parser needs to accept the hint
component. Now a new local function _snd_conf_generic_id() was
introduced to replace each call of "comment" and "type" field checks.
Also, the two existing identical functions for pcm and rawmidi are
removed and the new function is used commonly.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Since they are never changed it does not make sense to have them in
the writeable .data section, just make sure to add const to the ops
member in the structure definitions so that there are no extra
warnings added.
Signed-off-by: Diego E. 'Flameeyes' Pettenò <flameeyes@gmail.com>
