[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