On Wed, 18 Sep 2024 10:06:01 +0200,
Takashi Iwai wrote:
>
> On Tue, 17 Sep 2024 23:16:08 +0200,
> Jerry Luo wrote:
> >
> > On 9/17/24 5:50 AM, Christoffer Sandberg wrote:
> >
> > > From the dmesg logs it does look like the quirk is applied. Assuming
> > > the pci ids collide between these models (or the model param is used)
> > > which would explain why it gets applied:
> > >
> > > 1. Does the device have dual speaker pairs? If so (or if in doubt),
> > > check alsamixer for the codec and play around with the volume knobs
> > > to see if the controls affect the individual speaker pairs. Or try
> > > this https://github.com/alsa-project/alsa-ucm-conf/pull/410 to control
> > > both with the system volume control
> > > 2. If the device does not have dual speakers the quirk application
> > > probably
> > > needs to be extended with DMI specific info to limit it more.
> > >
> > > Let me know how it works,
> > >
> > > Christoffer
> >
> > From what I am can tell, and as mentioned in the tech specs, the
> > laptop only have two speakers, unlike the Sirius series.
> >
> > In case I didn't make it clear enough, the audio volume is normal now
> > for some unknown reasons. And no matter which kernel I change to, the
> > issue doesn't reappear.
> >
> > If you want a dmesg log from the kernel that used to not work, or any
> > other info, please let me know.
>
> I don't see any relevant about the incorrect volumes by the suggested
> commit, but at least we should avoid applying the quirk for a
> non-existing speaker pin.
>
> Jerry, yours is with CX11970 (codec id 0x14f120d0), right?
>
> Werner, how about your Sirius models? Are they also with the same
> codec chip?
> If they are different, we can have the additional checks
> for judging whether to apply the pincfg fix or not.
Or it's a question to Christoffer. Doesn't matter, if anyone can give
a info :)
thanks,
Takashi
[Index of Archives]
[Pulseaudio]
[Linux Audio Users]
[ALSA Devel]
[Fedora Desktop]
[Fedora SELinux]
[Big List of Linux Books]
[Yosemite News]
[KDE Users]