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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
