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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel




[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux