[alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config
Pierre-Louis Bossart
pierre-louis.bossart at linux.intel.com
Tue Nov 19 20:39:41 CET 2019
>>> +config SND_SOC_INTEL_USE_CTL_COMPONENTS
>>> + bool "Use CTL components for I/O configuration"
>>> + help
>>> + Some drivers might pass the I/O configuration through the
>>> + soundcard's driver name in the control user space API.
>>> + The new scheme is to put this information to the components
>>> + field in the ALSA's card info structure. Say Y, if you
>>> + have ALSA user space version 1.2.2+.
>>> +
>>
>> If this is at the board level, then maybe move this to
>> sound/soc/intel/boards/Kconfig
>>
>> I am not sure about the alsa-lib dependency, it's a bit odd, isn't it?
>> shouldn't this be handled via protocol versions? or a configuration
>> provided by alsa-lib somehow?
>
> It's not about the protocol. It's about to move this type of information
> to another place. I can remove the ALSA version sentence from the help,
> because it's just a hint. I would like to create ucm2 configurations
> based on this rather than the misused long card names.
I am with you on the idea, it's the transition that worries me. I guess
for a distro that would be fine, one would hope that there is a
communication between the alsa-lib and the kernel configurations parts,
but for a random user there's a chance that they would not select this
and not use ucm2 and vice versa.
it's also painful for kernel developers to rely on to-be-released
alsa-lib changes, we've been there with SOF and I don't know how many
times we had reports of issues related to alsa-lib setup problems. Here
it'd be worse since alsa-lib updates would need to be deployed on target
devices.
Again I am not against the idea, but anything we can do to reuse
friction during the transition will help a great deal.
More information about the Alsa-devel
mailing list