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.
thanks,
Takashi
[Index of Archives]
[Pulseaudio]
[Linux Audio Users]
[ALSA Devel]
[Fedora Desktop]
[Fedora SELinux]
[Big List of Linux Books]
[Yosemite News]
[KDE Users]