On Aug 30 2016 14:29, Takashi Iwai wrote:
On Tue, 30 Aug 2016 01:44:42 +0200,
Takashi Sakamoto wrote:
TLV feature of control interface is originally introduced at
commit 42750b04c5ba ("[ALSA] Control API - TLV implementation for
additional information like dB scale") and commit 8aa9b586e420 ("[ALSA]
Control API - more robust TLV implementation"). In this time,
snd_kcontrol_tlv_rw_t is for generating and transferring information about
threshold level for applications.
This feature can transfer arbitrary data in a shape of an array with
members of unsigned int type, therefore it can be used to deliver quite
large arbitrary data from user space to in-kernel drivers via ALSA control
character device. Focusing on this nature, commit 7523a271682f ("ASoC:
core: add a helper for extended byte controls using TLV") introduced
snd_soc_bytes_tlv_callback() just for I/O operations.
In this case, typically, APIs return operated length, while TLV feature
can't. This is inconvenient to applications.
The ASoC TLV (ab)usage still takes / receives the length field of
TLV. What's missing there?
I don't get exactly what you mean.
The issue in which I'm interested is that applications cannot get to
know length of actual processed bytes. Nothing others.
When pure threshold level information is transferred, applications can
get its length of TLV packet payload, because we have a loose protocol
to store the length of data in second element of the payload. The size
of 2 elements plus the length equals to the length of TLV packet payload.
When using TLV feature just for I/O, this protocol is not kept, as we
can see implementation of 'soc_bytes_ext' operation. Thus, the number of
processed bytes should be returned to applications, by any ways. This
patchset uses 'length' field in TLV packet header.
Regards
Takashi Sakamoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
