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

From: Jaroslav Kysela <perex@perex.cz>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	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 21:27:14 +0100	[thread overview]
Message-ID: <afd834ff-cfb8-404c-2246-1b11b28d142b@perex.cz> (raw)
In-Reply-To: <fb07b326-4c5d-43a7-4525-9d5fa71db95d@linux.intel.com>

Dne 19. 11. 19 v 20:39 Pierre-Louis Bossart napsal(a):
> 
>>>> +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.

I think that the most of issues were because there was no stable ucm upstream 
for SOF. I've seen multiple variants of UCM configuration files for SOF (and 
everything will be finalized with 5.5 kernel!).
  > 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.

Thinking more, we can create an ucm2 configuration which will handle both 
cases (independent on CONFIG_SND_SOC_INTEL_USE_CTL_COMPONENTS). I prepared an 
example:

https://github.com/alsa-project/alsa-ucm-conf/commit/f1c0083483e184eb7a5eee1f7d8cb4df66cac085

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel