> Why I use the metadata ioctl is because the ALSA controls are binding > to the sound card. What I want is the controls can be bound to > snd_compr_stream, because the ASRC compress sound card can > support multi instances ( the ASRC can support multi conversion in > parallel). The ALSA controls can't be used for this case, the only > choice in current compress API is metadata ioctl. I don't know if there is really a technical limitation for this, this is for Jaroslav to comment. I am not sure why it would be a problem to e.g. have a volume control prior to an encoder or after a decoder. > And metadata > ioctl can be called many times which can meet the ratio modifier > requirement (ratio may be drift on the fly) Interesting, that's yet another way of handling the drift with userspace modifying the ratio dynamically. That's different to what I've seen before. > And compress API uses codec as the unit for capability query and > parameter setting, So I think need to define "SND_AUDIOCODEC_SRC' > and 'struct snd_dec_src', for the 'snd_dec_src' just defined output > format and output rate, channels definition just reuse the snd_codec.ch_in. The capability query is an interesting point as well, it's not clear how to expose to userspace what this specific implementation can do, while at the same time *requiring* userpace to update the ratio dynamically. For something like this to work, userspace needs to have pre-existing information on how the SRC works.
