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

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

 



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@xxxxxxxx>

--

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@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.




[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