[alsa-devel] UCM extensions

[Kai Vehmanen]

Hi,

On Thu, 7 Nov 2019, Jaroslav Kysela wrote:

> Dne 07. 11. 19 v 11:18 Cezary Rojewski napsal(a):
> > On 2019-11-05 20:36, Jaroslav Kysela wrote:
> > However, I have some concerns here. First, could you elaborate on "we
> > require for the SOF kernel driver"?
> 
> Please, look here:
> 
> https://github.com/alsa-project/alsa-ucm-conf/commit/a8253465aef2df494ccd5b1103412b0318be582e#diff-a2ba34aee1a55c2fd664d78624477173L37
> 
> The HDA driver sometimes manages different JackControl names depending on the 
> used codec and it would be the real maintenance mess to use the DMI info (long 
> card name) for all possible configurations.
> 
> Also, if you look to the current configs, many duplications can be removed 
> with the If evaluations.

yes, I agree with Jaroslav here. There's definitely the risk of making 
UCM files too complex, but pragmatically, we really need something between 
the current boolean choice between a generic UCM picked by card 
shortname and per-product tailored UCM'es picked up by card longname.

There's some variation in HDA codec controls that is more
convenient to hide in if-else logic in the generic UCM. Same goes 
for addition of controls to the kernel. Without conditional logic, using 
a newer UCM file with an older kernel simply breaks -- even if the change
is incremental only.

There was a discussion in the summer on the list about adding versions in 
kernel and using that to help pick the right UCM profile. This isn't an 
easy path either -- there are many components contributing to the 
overall card interface on kernel side, and you still need to pick (or 
compile at runtime) a single UCM file. It would seem with Jaroslav's 
current proposal, you could cover majority types of minor variations
and thus significantly limit the number of UCM files that need to be 
maintained.

Br, Kai