[alsa-devel] [PATCH 1/4] ALSA: control: return payload length for TLV operation

[Takashi Sakamoto]

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