Speaker issues

[oppsig]

Hello, thanks for your research so far!
I think i have the same laptop but model number 14ACN06.
Just wondered how are you detecting that the back speakers are not working?
If i put volume to 100% and run "speaker-test -c 4 -t wav" I can hear sound on both what appears to be the front and back speakers but the sound is so low, thin and treble on all speakers.

In pulseaudio volume control outputs I can only see speakers, not front/back channels etc.

lspci -v gives me realtek alc287 but according to specs laptop is running alc3306.

Do you think this could be related to this kernel issue with other laptops
https://bugzilla.kernel.org/show_bug.cgi?id=208555#c547
See comment 547!

Im on:
Linux 5.16.9-arch1-1 #1 SMP PREEMPT Fri, 11 Feb 2022 22:42:06 +0000 x86_64 GNU/Linux

[milkovsky]

Hi @oppsig ,

first of all good choice :) the laptop hardware looks very promising.

Just wondered how are you detecting that the back speakers are not working?

I had a dual-boot with Windows and Ubuntu. The sound difference was clearly noticeable for me acoustically:

• In Ubuntu it was as you said low and thin.
• In Windows it was much louder and had bass.

From what I saw in review, this laptop has 4 speakers. I assumed it was the issue that some of the speakers did not work. I did an ear test, I just put my ear close to the laptop and listened :-D
Also I found some similar reports about this, and just assumed, that only 2 speakers work.
I tried various settings in hdajackretask, but could not find a right combination.

P.S. I can not test this right now as I have sent my laptop back because of an issue with built quality. The body was not balanced, as result the laptop was wobbling on a table. I am thinking about purchasing the same laptop again. Waiting for some better price, it is currently 200EUR more than before.

[oppsig]

I think your correct regarding the speakers though. The laptop contains two tweeters and two subwoofers. According to that kernel thread the subwoofers are not detected.

[joesteffee]

Curious if anyone has made any progress on this. I also just bought the same laptop (14ACN6) and everything works amazingly for linux except the speakers. I'm on Arch (mainline kernel 5.18) and have tried the custom compiled kernel with:

CONFIG_SND_HDA_SCODEC_CS35L41_I2C=y
CONFIG_SERIAL_MULTI_INSTANTIATE=y

with no change. I've also tried every combination of enabling jacks in hdajackretask to no avail. Interestingly enough, I get very faint output from 5 distinct speakers with:

speaker-test -c 5 -t wav

Front Left and Front Right come through with just treble, The rear left and rear right tests do come through on the bottom of the laptop but very faint. I have to press my ear up against the bottom of the laptop to hear it on either side. There also appears to be a front center speaker which sounds quite normal in the hinge at the bottom of the screen. I think all the speakers are working its just a matter of tuning them properly and setting levels.

Does anyone know how to start a bug bounty for this? It would be nice to have this otherwise perfect laptop working 100% and Lenovo doesn't really seem interested in supporting it.

I'm happy to share any relevant debug info that might help get this resolved.

[oppsig]

I did create an issue at bugzilla. https://bugzilla.kernel.org/show_bug.cgi?id=215632
I also tested with speaker-test, two of the speakers should be subwoofers, and there is no difference in sound quality using speaker test. It does sound like the back speakers are coming more from back but I'm guessing it's probably the same speakers.
I also tested 5.18-rc1, no difference.

[oppsig]

I don't know which sound amplifier is in this laptop, if it is CS35L41 or not? But maybe it is possible to ask Lenovo directly.

[milkovsky]

@oppsig, have you asked Lenovo about the amp?

[githubee]

speaker-test -c 5 -t wav

seems to work with kernel 5.13 on ubuntu 21.10. same experience as yours, the back arent loud at all. i thought kernel 5.18 would fix the issue according to this comment https://bugzilla.kernel.org/show_bug.cgi?id=208555#c591

[milkovsky]

@githubee thank you for posting this, looking forward to the next kernel update

[milkovsky]

seems to work with kernel 5.13 on ubuntu 21.10. same experience as yours, the back arent loud at all. i thought kernel 5.18 would fix the issue according to this comment https://bugzilla.kernel.org/show_bug.cgi?id=208555#c591

@githubee, I installed Pop!_OS 22.04 LTS x86_64, Kernel: 5.18.10-76051810-generic. Subwoofers still do not produce any sound.

[githubee]

super disappointed. i wish i would know how to help. i switched to windows and will probably just use WSL. shutdown also didnt work as well as sleep. too many bugs.

[milkovsky]

I have tried the new Ubuntu 22.10 today to check if Pipewire fixed anything. No luck, the subwoofers do not wotk still.

[githubee]

I can confirm. Seems like nobody is supporting it. I will probably switch back to Thinkpad :'(

[AlexMV12]

I confirm, that's unfortunate. The laptop is very good for its price, but this speaker problem + the various shutdown/suspend ones are very annoying.

[tirithen]

I use this laptop daily with Arch Linux, I'm happy to find others with similar problems. To me everything except the sound from the speakers works very well.

I use the laptop with headphones and I'm still satisfied enough, not using Linux is a blocker for me.

Fingers crossed someone can find a solution for this. Kernel development is outside of my skill set, but do let me know if I can help out with Arch Linux testing on the machine itself.

[choikangjae]

Any updates here? I am having same issues and very likely nobody is supporting it.

[milkovsky]

Unfortunately no updates so far. You can check the related links, kernel issue reports:
https://github.com/milkovsky/Linux-on-Lenovo-Slim-7-Carbon-AMD#speakers

[milkovsky]

Short update: The issue is still present in Pop!_OS 22.04 LTS, 6.2.6-76060206-generic

[tirithen]

Without knowing much about device fixups, It seems to me like the problem might be in the kernel patch_realtek.c file, and that we there lack a "fixup" for this laptop model and its ALC3306 codec. There are a lot of specific fixups in that file accociated with a specific model for example "ALC287_FIXUP_YOGA7_14ITL_SPEAKERS".

So we would somehow find the correct pins, and the correct values to set for those pins and add a case for this model in this file right?

It also seem like the datasheet for ALC3306 specifying the pinout and possible values is hard to find on the internet right? Is there a way to extract these values from the Windows binary drivers? That is beyond my current skillset.

I also found another issue that seem related to the same codec on the alsa-project alsa-project/alsa-lib#139

Is there any person with deeper knowledge in these areas that we can turn to for advice? It seems like the people writing here currently has a limited knowledge about the specific details of how to "fixup" audio devices for the linux kernel? I certainly know to little at this point.

[tirithen]

Other kernel bug reports that seem related to ALC3306:

• https://bugzilla.kernel.org/show_bug.cgi?id=216299#c3
• https://bugzilla.kernel.org/show_bug.cgi?id=208555

[milkovsky]

@tirithen you are absolutely right. We need to figure out how to patch the patch_realtek.c with the right values. Unfortunately I do not have an appropriate experience/knowledge for this.
Here are more related links to the topic: https://github.com/milkovsky/Linux-on-Lenovo-Slim-7-Carbon-AMD#speakers

[tirithen]

To really gather all information needed it seems like we would really need to access the datasheet for the ALC3306 codec from Realtek, is there any chance of just asking them for access to the datasheet?

I wish there was a way, I suppose that the binaries for the Windows drivers might contain the pin configurations, and any specific actions to add to the fixup? I wonder how these things are usually resolved.

---

Not that it solved much perhaps, but I did probe around with ChatGPT with the links provided on the page you posted as well as have it analyze the patch_realtek.c code, as my skill-set is to limited to write the code on my own. After a lot of messaging it derived this list of steps needed to create the fixup, and which pieces that are missing:

ChatGPT:
Based on our step-by-step list and the information we've gathered so far, here's what we have:

• Identify the Codec: We've identified the codec as ALC3306.
• Identify the Nodes: We've identified the nodes as 0x21, 0x22, and 0x1a.
• Understand the Existing Fixups: We've analyzed the structure of existing fixups in the patch_realtek.c file.
• Understand the Pin Configurations: We've identified that the pin configurations for the nodes are likely to be set to specific values to enable the speakers. However, we still need to determine the exact values for these configurations.
• Create a New Fixup: We've understood the structure of a fixup and how to add it to the alc_fixups array. However, we still need to determine the specific actions that our fixup needs to perform.
• Test the Fixup: We haven't reached this step yet.

So, the missing information we need to create the fixup is:

• The exact pin configurations for the nodes 0x21, 0x22, and 0x1a.
• The specific actions that our fixup needs to perform to enable the speakers.

Once we have this information, we can proceed to create the fixup and then test it.

Me:
Great! So, how will we find the exact pin configurations for the nodes 0x21, 0x22, and 0x1a directly on the internet without contacting Realtek? Can you search through the link/references that we have already found for the complete details about the pin configurations?

ChatGPT:
I have searched through the links and references that we have already found, but unfortunately, I could not find the complete details about the pin configurations for the nodes 0x21, 0x22, and 0x1a. The information available is not sufficient to determine the exact pin configurations.

The best course of action would be to contact Realtek directly or refer to the specific datasheet or technical manual for the audio codec in question. These documents usually provide detailed pin configuration information. If you have the model number of the Realtek audio codec, I can help you search for its datasheet or technical manual.

[milkovsky]

Nice research! Thanks for sharing.
We could also ask the others community on how did they make the fixups for the other laptops with Realtek.

[ShalokShalom]

I contacted Realtek to provide the specification for the ALC3306 and found this repo, who configured the sound for the regular Lenovo Slim 7.

Its another driver, and a very specific issue from what I see, so its most likely not helpful.

Still wanted to share.

[tirithen]

The dream is alive, one day maybe our laptops can use their speakers properly.

[ShalokShalom]

I read in the bugzilla issue that linux 6.7 fixed the issue on a similar device.

[InfinityRed-Code]

Tried to recreate it with my own device. No luck so far.
Still waiting on the official 6.7 kernel for fedora 39. The test-kernel did not work for me. The reporter provied an alsa-info stream. Worth noting is that alsa still shows ALC287 not ALC3306.
Asked him for a confirmation on the sound setup that is beeing displayed in settings

[tirithen]

I'm using kernel 6.7.3-arch1-2 on Arch Linux, no luck so far, but then I have not tried to make any specific setup. If there are any settings that I would need to have the speakers working, I can give them a try on this kernel version.

[ShalokShalom]

To really gather all information needed it seems like we would really need to access the datasheet for the ALC3306 codec from Realtek, is there any chance of just asking them for access to the datasheet?

I wish there was a way, I suppose that the binaries for the Windows drivers might contain the pin configurations, and any specific actions to add to the fixup? I wonder how these things are usually resolved.

Not that it solved much perhaps, but I did probe around with ChatGPT with the links provided on the page you posted as well as have it analyze the patch_realtek.c code, as my skill-set is to limited to write the code on my own. After a lot of messaging it derived this list of steps needed to create the fixup, and which pieces that are missing:

ChatGPT: Based on our step-by-step list and the information we've gathered so far, here's what we have:

• Identify the Codec: We've identified the codec as ALC3306.
• Identify the Nodes: We've identified the nodes as 0x21, 0x22, and 0x1a.
• Understand the Existing Fixups: We've analyzed the structure of existing fixups in the patch_realtek.c file.
• Understand the Pin Configurations: We've identified that the pin configurations for the nodes are likely to be set to specific values to enable the speakers. However, we still need to determine the exact values for these configurations.
• Create a New Fixup: We've understood the structure of a fixup and how to add it to the alc_fixups array. However, we still need to determine the specific actions that our fixup needs to perform.
• Test the Fixup: We haven't reached this step yet.

So, the missing information we need to create the fixup is:

• The exact pin configurations for the nodes 0x21, 0x22, and 0x1a.
• The specific actions that our fixup needs to perform to enable the speakers.

Once we have this information, we can proceed to create the fixup and then test it.

Me: Great! So, how will we find the exact pin configurations for the nodes 0x21, 0x22, and 0x1a directly on the internet without contacting Realtek? Can you search through the link/references that we have already found for the complete details about the pin configurations?

ChatGPT: I have searched through the links and references that we have already found, but unfortunately, I could not find the complete details about the pin configurations for the nodes 0x21, 0x22, and 0x1a. The information available is not sufficient to determine the exact pin configurations.

The best course of action would be to contact Realtek directly or refer to the specific datasheet or technical manual for the audio codec in question. These documents usually provide detailed pin configuration information. If you have the model number of the Realtek audio codec, I can help you search for its datasheet or technical manual.

Could we test this methodologically by ourselves? Without having access to the specification?
So, could we just try pin for pin, or something like that?

I would also look out for a dedicated Linux audio driver specialist, and ask them directly about what we can do.

Do we know some usergroup, outside of the Kernel mailing list, that can help us there?

[tirithen]

@ShalokShalom I found another repo with discussions on broken yoga speakers that seem to have made some progress upstream in the linux kernel version 6.8+ on their model Lenovo Yoga 7 Gen 7 AMD 14ARB7. I have kernel version 6.8.4 myself and that was not enough for my Yoga Slim 7 Carbon 14ACN6.

I posted about our repo and issues at tomsom/yoga-linux#3 (comment) , hopefully they might have some hints about how to take this forward.

Maybe there are more groups like this out there, that we can search and find? Try searching and asking around some more maybe?

[ShalokShalom]

Same. I am on 6.8.6, still the same.

[stu-gee]

Recently installed PopOS on my Lenovo Slim Pro 7 and am a little confused on if the speakers are working properly out of the box or not.

Here's what I'm running:

OS: Pop!_OS jammy 22.04 x86_64
Kernel: Linux 6.9.3-76060903-generic

Read through the various links shared here and I believe it's working as intended as I'm on the latest kernel - however I'm confused if the sound setting should be setup as Analog Stereo Output or something else.

I've tried setting it to Analog Surround 4.0 but then get the tinny/quiet sound in back speakers as others reported. However, running the command speaker-test -c 5 -t wav works flawlessly.

Hope others can shed some light on this - thanks :)

[ShalokShalom]

I think the Pro 7 is a different device than the Slim 7, and I dont know if you have the same issues, we do.

If you are uncertain if the speakers working properly or not, you have certainly not the same issue, as we do. 🙂

Ours is VERY noticable, and I recommend you to write to the kernel mailing list.

What we should maybe do as well, as there is no activity for a long time now about our issue.

[oppsig]

Regarding our issue @soyersoyer sent me this message:

oppsig: Please write to one of the Cirrus Logic Audio Codec maintainers, or to their list.
M: James Schulman [email protected]
M: David Rhodes [email protected]
M: Richard Fitzgerald [email protected]
L: [email protected] (moderated for non-subscribers)
L: [email protected]

I haven't done it myself so if someone else wants to contribute, feel free 😀

[ShalokShalom]

I did send the first three mailing addresses a notice, and linked this thread.
Thanks a lot

[ShalokShalom]

I got answer:

The SKU in question isn't currently scheduled for support, however if you create a bugzilla ticket at the below address and CC Cirrus Patches ([email protected]) to it, we will investigate adding support as soon as we can.

https://bugzilla.kernel.org/

[ShalokShalom]

I finally got to do this, and ironically, they seem to have not known, that the bug reports that we were discussing here, already existed.

I added them now (4 years after creation) to that list, as they had not known about it appearently.

Neither the issue about the alc287, nor that one about the alc3306 had Cirrus at the CC.
That seems kinda confusing, as the comments even speak about "getting out a driver from Cirrus".

[oppsig]

I did create a bugzilla report for this issue more than two years ago.

bugzilla

[oppsig]

I think I have added [email protected] to CC on that bug now!

[milkovsky]

I did create a bugzilla report for this issue more than two years ago.

@oppsig, yes. Thank you for creating this bug report. This report is also mentioned in this repository.

The bugzilla bug report is currently assigned to Jaroslav Kysela, but I am not sure if he is working on it.

[oppsig]

No it has been assigned to him the whole time, so I don't think he is working on it.
Maybe that patches mailing list will pick it up eventually, but I don't know.

[oppsig]

Got a comment earlier today on bugzilla bug report that drivers are in development and will be sent upstream once finished and testet. Great news!

[tirithen]

Oh! All the music we will listen to soon! fingers crossed

[ShalokShalom]

We got a patch

https://bugzilla.kernel.org/show_bug.cgi?id=215632

[oppsig]

Yeah, gonna test it out very soon.

[milkovsky]

I am suspicious about the SND_PCI_QUIRK(0x17aa, 0x3856, "Legion 7 14ACN6", ALC287_FIXUP_LEGION_14ACN6), line there. It doesn't sound like our laptop. I would expect to see there smth like Yoga Slim 7 Carbon 14ACN6.
But as long as 14ACN6 matches, it should be ok.

[oppsig]

Hehe, yes it should maybe be renamed, but I remember those numbers, it matches info from alsainfo!
So it should match on subsystem Id, I don't think name is important here.

Codec: Realtek ALC287
Address: 0
AFG Function Id: 0x1 (unsol 1)
Vendor Id: 0x10ec0287
Subsystem Id: 0x17aa3856
Revision Id: 0x100002

[oppsig]

This is probably the name that should be used in patch yes.

!DMI Information
!!---------------

Manufacturer: LENOVO
Product Name: 82L0
Product Version: Yoga Slim 7 Carbon 14ACN6
Firmware Version: H5CN31WW
System SKU: LENOVO_MT_82L0_BU_idea_FM_Yoga Slim 7 Carbon 14ACN6
Board Vendor: LENOVO
Board Name: LNVNB161216

[oppsig]

I'm compiling this now, but takes a while since i didn't disable any modules.
Using linux-tkg with user patches and compiling vs 6.11.1.

[oppsig]

So he is working on patch, and doing diagnostics, so hopefully we will have something working soon now.

[milkovsky]

@oppsig I want to say a big thank you for all the work in the kernel issue queue!
If I can help you somehow, please let me know.
I am not familiar with applying core patches, but with some instructions I can manage it.

[oppsig]

Thank you @milkovsky :) No worries, I'll try to help with what I can.
But so far as you have probably read, after debugging the device we need help from realtek to provide clock to the cirrus amps via the realtek codec.
so we need a quirk from them in order to continue, which is kinda sad.
I don't know who to contact, but I've tried added a few realtek guys who have contributed to the patch_realtek.c file, in hope that someone there can help us.

[ShalokShalom]

Do we have any new info, please