Re: [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config - Pierre-Louis Bossart

From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Jaroslav Kysela <perex@perex.cz>,
	ALSA development <alsa-devel@alsa-project.org>
Cc: Takashi Iwai <tiwai@suse.de>, Mark Brown <broonie@kernel.org>
Subject: Re: [alsa-devel] [PATCH 2/2] ASoC: Intel - use control components to describe card config
Date: Tue, 19 Nov 2019 13:39:41 -0600	[thread overview]
Message-ID: <fb07b326-4c5d-43a7-4525-9d5fa71db95d@linux.intel.com> (raw)
In-Reply-To: <f2de9597-c9c2-7696-622b-a2bbc2c32bb7@perex.cz>

>>> +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.

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel