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

[Takashi Iwai]

On Wed, 31 Aug 2016 17:26:14 +0200,
Takashi Sakamoto wrote:
> 
> On Aug 31 2016 21:08, Takashi Iwai wrote:
> > On Wed, 31 Aug 2016 13:54:37 +0200,
> > Clemens Ladisch wrote:
> >>
> >> Takashi Iwai wrote:
> >>> TLV has never been and (will never be) an API to handle a
> >>> generic binary stream.
> >>
> >> It would be possible to define something like SNDRV_CTL_TLVT_HWDEP_BLOB
> >> or _COEFFICIENTS, or to reserve a range of TLVT values for driver-
> >> defined types.  (But we cannot change soc-wm-adsp to support only proper
> >> TLV data, because this would introduce a regression.)
> > 
> > Well, passing the random hw-specific data is fine, but what I meant is
> > that a "stream" isn't suitable with TLV.  (And I don't mean it's
> > impossible, either :)
> 
> I'm few interested in whether it's binary stream or not, or
> hardware-specific or not. The returned length is the most, in a point of
> application developers. I'll show you two cases.
> 
> 1.Let's see current implementation of 'snd_soc_bytes_tlv_callback()' in
> sound/soc/soc-ops.c.
> 
> http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/soc/soc-ops.c?h=v4.8-rc4#n772
> 
> Here, 'size' argument is struct snd_ctl_tlv.length and 'tlv' argument is
> &struct snd_ctl_tlv.tlv[2].
> 
> The size of actual I/O is smaller value between the length and hardcoded
> 'params->max'.
> 
> When applications give larger buffer to TLV feature of ALSA control
> interface, then the early part of the buffer is filled. On the other
> hand, applications cannot get to know the actual length.
> 
> 2.Let's see core implementation user-defined control element set.
> 
> http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/core/control.c?h=v4.8-rc4#n1140
> 
> The 'size' and 'tlv' arguments are the same as the first example.
> 
> When write operation, the given buffer and length is stored to a control
> element set. When read operation, the given buffer is filled by the
> stored data with the stored length. On the other hand, applications
> cannot get to know the actual length.
> 
> When we're considering just about pure threshold information, there's no
> concern about the length, due to struct snd_ctl_tlv.tlv[1]. But now
> we've already decided to use this feature to transfer arbitrary length
> of data. It's better to consider about what is better for applications.

Which application do you have in mind?  Applications would access via
either alsa-lib or tinyalsa.  And these libraries do already care
about how to access via TLV.  What makes better what, practically
seen?


Takashi