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/s...
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/...
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