[PATCH] [RFC] ALSA: hda: Fix the control element identification for multiple codecs

[Jaroslav Kysela]

On 31. 01. 23 9:42, Takashi Iwai wrote:
> On Mon, 30 Jan 2023 09:21:18 +0100,
> Jaroslav Kysela wrote:
>>
>> [This is a RFC for the discussion]
>>
>> Some motherboards have multiple HDA codecs connected to the serial bus.
>> The current code may create multiple mixer controls with the almost
>> identical identification.
>>
>> The current code use id.device field from the control element structure
>> to store the codec address to avoid such clashes for multiple codecs.
>> Unfortunately, the user space do not handle this correctly. For mixer
>> controls, only name and index are used for the identifiers.
>>
>> This patch fixes this problem to compose the index using the codec
>> address as an offset in case, when the control already exists. It is
>> really unlikely that one codec will create 10 similar controls.
>>
>> This patch adds new kernel module parameter 'ctl_dev_id' to allow
>> select the old behaviour, too.
>>
>> BugLink: https://github.com/alsa-project/alsa-lib/issues/294
>> BugLink: https://github.com/alsa-project/alsa-lib/issues/205
>> Fixes: 54d174031576 ("[ALSA] hda-codec - Fix connection list parsing")
>> Fixes: 1afe206ab699 ("ALSA: hda - Try to find an empty control index when it's occupied")
>> Signed-off-by: Jaroslav Kysela <perex at perex.cz>
>>
>> --
>>
>> Discussion:
>>
>> There are several possibilities to handle the old behaviour - a kernel
>> module parameter (proposed), a kernel configuration option or drop
>> the old behaviour completely.
> 
> Dropping is likely no-go, as we don't even know whether it really
> breaks or is safe, I suppose.  The module option sounds like a
> feasible workaround, maybe with the default behavior defined by
> kconfig.  And we can put some message for the old behavior to mention
> it'll be deprecated, for example.  Then after some time, we can really
> drop the old behavior, too.

OK. I'll add a Kconfig default to my patch. I assume that the default preset 
will be the new behaviour.

> One more question is which driver provides the option.  Does this
> problem happen with SOF HDA driver, too?

I think that this hardware is rare and I've not seen this combination of HDA 
codecs with SOF yet. From the googling and the alsa-info database analysis, 
it's an old issue touching some "hi-end" ATX motherboards. Basically, 
pulseaudio nor pipewire can work with this hardware properly, because the 
mixer cannot be initialized.

					Jaroslav

-- 
Jaroslav Kysela <perex at perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.