Re: [REGRESSION][BISECTED] Audio volume issues since 4178d78cd7a8

[Christoffer Sandberg]

On 4.10.2024 10:25, Takashi Iwai wrote:
> On Fri, 04 Oct 2024 10:18:10 +0200,
> Christoffer Sandberg wrote:
> > On 2.10.2024 23:28, Jerry Luo wrote:
> > > On 10/2/24 10:00 AM, Takashi Iwai wrote:
> > >> On Wed, 02 Oct 2024 10:21:22 +0200,
> > >> Christoffer Sandberg wrote:
> > >>>
> > >>>
> > >>> On 30.9.2024 09:44, Takashi Iwai wrote:
> > >>>> On Mon, 23 Sep 2024 21:37:42 +0200,
> > >>>> Jerry Luo wrote:
> > >>>>>
> > >>>>> Hi Takashi,
> > >>>>>
> > >>>>> On Mon, 16 Sep 2024 19:22:05 +0200,
> > >>>>>
> > >>>>> Takashi Iwai wrote:
> > >>>>>
> > >>>>>      Could you give alsa-info.sh output from both working and
> > >>>>> non-working
> > >>>>>      cases?  Run the script with --no-upload option and attach the
> > >>>>> outputs.
> > >>>>>
> > >>>>>      thanks,
> > >>>>>
> > >>>>>      Takashi
> > >>>>>
> > >>>>> Issue now reappear, output from alsa-info.sh are attached. If they
> > >>>>> are still
> > >>>>> needed.
> > >>>> Thanks.  The obvious difference seems to be the assignment of two
> > >>>> DACs
> > >>>> 0x10 and 0x11 for headphone and speaker outputs.
> > >>>>
> > >>>> Christoffer, how are those on your machines?
> > >>> I attached alsa-info from the Sirius Gen2 device.
> > >>>
> > >>> Comparing the working/nonworking of Jerry, yeah, the assignment of
> > >>> 0x10 and 0x11 looks switched around. I don't see what difference this
> > >>> would make. Also, node 0x22 has "bass speaker" controls in the
> > >>> non-working version.
> > >>>
> > >>> Comparing the Sirius Gen2 alsa-info with Jerrys, to me it looks like
> > >>> the non-working version corresponds to our working version.
> > >>>
> > >>> I would expect the non-working version to happen all the time though
> > >>> with regards to the "bass speaker" controls. Why would this only
> > >>> happen sometimes?
> > >> Thanks!  The assignment of DACs depend on the pins and topology, so it
> > >> can be a bit sensitive.
> > >>
> > >> Now looking more closely at both outputs, I wonder how the commit
> > >> breaks pang14.  Maybe it has a PCI SSID 2782:12c5 (or 12c3) while the
> > >> codec SSID is 2782:12b3?  If so, the patch below should fix.
> >
> > Interesting, you're right, PCI SSID c3/c5 and codec SSID c3/c5 for the
> > Siriuses.
> >
> > I had a look around. In patch_realtek there are some cases where codec
> > SSID match is needed as well. Would it be better/safer to directly do
> > this immediately or keep it as an exception where it breaks or for
> > known sensitive models/brands?
>
> It needs a better handling, yes.  OTOH, the driver became gigantic and
> it's very tough to change the basic matching stuff.  That is, we can't
> flip from PCI SSID to codec SSID out of sudden, as it'll break
> certainly many other systems.
>
> What I have in mind is to add an extra flag to the matching table to
> indicate the codec SSID matching, something like:
>
> --- a/sound/pci/hda/hda_local.h
> +++ b/sound/pci/hda/hda_local.h
> @@ -282,6 +282,7 @@ struct hda_fixup {
>  	int type;
>  	bool chained:1;		/* call the chained fixup(s) after this */
>  	bool chained_before:1;	/* call the chained fixup(s) before this */
> +	bool match_codec_ssid:1; /* match with codec SSID instead of PCI SSID 
> */
>  	int chain_id;
>  	union {
>  		const struct hda_pintbl *pins;

Sounds reasonable to me. It would mean either-or then though.

> Although this will help in this case, many of existing code do check
> codec ID in addition to PCI SSID, and this flag won't help for them as
> is.

For the fixups where codec SSID is already known for all cases it would 
be possible to represent current logic with matching both SSIDs.

Otherwise I can not judge whether matching both PCI SSID and codec SSID 
at the same time would be needed.

In any case, your approach would reduce code size if this is a recurring 
thing.