galliumos-distro
galliumos-distro copied to clipboard
GalliumOS
Internal microphone does not work on Braswell / Realtek ALC5645
We're pulling in future mainline code from @plbossart's experimental repo, for the chtrt5650 drivers in 4.9.4-galliumos kernels. Watch for updates.
Workaround options: Bluetooth or USB microphones/headsets, including USB-to-3.5mm jacks.
I'm working with @plbossart to obtain the information necessary to get the microphone working and will leave a comment here when it is operational.
BTW - found that using Bluetooth headset is a workaround. Just switch device input to use BT headset. I've ordered a USB microphone - will update when I've tried that next.
@drrwebber USB mics will work too. I should have added workaround options to the initial description; will do so now. Thanks for mentioning it!
Any ETA from @reynhout or @evan-a-a ?
Trying to use the GalliumOS Samsung 3 Chromebook in a classroom setting where we do need individual microphones to perform speech recognition. I can't dive too deeply into this one myself yet, even though it really just amounts to pulling code from upstream.
Going to try using the USB microphones as a workaround: https://www.amazon.com/gp/product/B0171MRGME for now until things are operational.
Ideally, the internal mics work.
@chuckhacker no ETA. Pulling code from upstream won't work unless the problem is fixed in upstream. USB mics are the best answer for now.
I like that USB $20 boom mic - I should have ordered one of those! Instead I have the Samson Go Mic which is studio quality - but super portable.
What people need to know is that this is NOT a GalliumOS problem - its in the underlying ALSA support and the audio chipset in the Chromebook and its firmware - https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture
Sadly no quick fix - ugly - so when ALSA solves this - then we all get this working again. In the meantime - USB mic' easy plug and play solution.
@drrwebber, does that mean that we are at the mercy of ALSA? Because if that is the case, it seems that this issue may never get fixed. Is that the current situation? If so, please confirm, as I may want to return my EDGAR. Despite it being a terrific value, it can't be a daily driver (especially for travel) without a working built in mic.
@xmbwd We have a history of fixing audio (in/out) on ChromeOS devices even when it is not fixed upstream or in other distros, and it is a priority for us...but unfortunately we can't (ever) make any promises about specific models or timelines.
@xmbwd IDNK - but I did find this trouble shooting - https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture/Troubleshooting#Microphone
And tried alsamixer in terminal - and PulseAudio tweaking.
I got as far as the crackling and poor sound quality input working with Audicity - I did not try the config changes they suggest - my external mic arrived and its so much better than any built-in mic.
I have the Acer Chromebook 14 and I'm keeping it - so good on all other fronts! So not sure if your EDGAR can be coaxed better on the microphone.
Thanks @reynhout, that distinction helps. I'm good waiting for you guys and completely understand.
And thanks @drrwebber as well.
Does anyone have a link to the patches that @plbossart has for testing? I tried a 4.10.10 kernel to see if his commits in that kernel fixed this problem. Sadly they didn't. I'm also looking to fix #318 if anyone has patches to try for that one.
@chrisjohgorman Microphone has not been resolved yet. For updates, follow the kernel bug report. https://bugzilla.kernel.org/show_bug.cgi?id=95681
New kernel commit in that thread about analog mic on 5645: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20180104&id=b70b309950418437bbd2a30afd169c4f09dee3e5
Is this relevant here? I have no idea if my mic on Edgar is analog or digital...
@mathnic Good question! Fortunately, this patch is included in the 4.14.12-galliumos1 kernel currently in the testing repo.
I just tested the mic on TERRA (also Braswell & RT5645) on the new kernel. After some futzing with alsamixer, I can see meter movement when tapping the mic itself, so it's possible that careful tuning would yield a usable internal mic. Further futzing required, but I'm hopeful.
Ah. Good to know it's in testing. I just did the update but no change in mic functionality. On Edgar, I've had mic response from tapping it for quite some time. Anyhow, I'll try some futzing myself:) Thanks for the new kernel and all good work!
No love so far on CELES. Mic input device opens but only records noise. Don't see much I can do in alsamixer?
@reynhout
As far as I can judge the patch from Hans de Goede
ASoC: Intel: cht_bsw_rt5645: Analog Mic support
has been merged to kernel 4.16-rc1
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?h=v4.16-rc1&qt=grep&q=rt5645
I was installing 4.16-rc2 on my Edgar, mic not working.
However Edgar is rt5650, no rt5645. I found the corresponding mailing list conversation
https://www.spinics.net/lists/alsa-devel/msg71865.html
They report the mic should be usable, even with some noise. Hope, that helps.
Sorry for the delay in replying, there is no news on the internal microphone for my laptop. The laptop is a braswell and the chip is a realtek 5650. I believe there has been progress with the realtek 5645. The kernel thread is https://bugzilla.kernel.org/show_bug.cgi?id=95681.
I can confirm in RELM that internal microphone does not work. Also, when connecting a hands-free pair in the 3.5mm jack, it defiantly takes in audio but you can barely listen to it (edit: using them in my android phone works fine.)
Haven't been able to test but I think this Linux patch might fix the microphone https://mailman.alsa-project.org/pipermail/alsa-devel/2019-October/156099.html
I tried the new kernel, but haven't got any sound into the machine via the microphone. It does show my sound card as having the quirk, but that's all I've got at the moment. (I must admit I haven't looked too deeply at it.) I am not too sure if I have a digital or analog microphone. It's a chtrt5650, so I think it has a digital microphone, which may mean loading some modules for it. Perhaps I will try some testing today to see if I can get anything from it.
Chris
On Fri, Jan 31, 2020 at 10:34 AM v0idifier [email protected] wrote:
anyone in 5.5 was able to test?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/GalliumOS/galliumos-distro/issues/319?email_source=notifications&email_token=AG76X47TKI2MLNG3LDR6THTRARAJLA5CNFSM4C45KEC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKPANKA#issuecomment-580781736, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG76X4YZQ5FXJZCQ6CKYSI3RARAJLANCNFSM4C45KECQ .
Hope no one is bothered by my replying to my own post. I have done some digging into the microphone issue and have found.
Daniel Stuart found that cht_bsw_max98090_ti boards need a clock line, pmc_plt_clk_0, enabled in order to process audio properly. This fix covers rambi variant boards. (glimmer, clapper, swanky, enguarde, winky, kip, squawks, orco, ninja, heli, sumo, banjo, candy, gnawty, rambi and quawks)
https://lore.kernel.org/alsa-devel/[email protected]/t/#m309436974c5acd96b8c226ca5d00b35de9bd7afa
Sam McNally found that Strago family Chromebooks use pmc_plt_clk_0 for the codec mclk, resulting in white noise with some digital microphones. This is me. I have a banon chromebook from the strago family. (banon, celes, edgar, reks, setzer, ultima, cyan, kefka, relm, terra, wizpig.)
https://github.com/torvalds/linux/commit/adebb11139029ddf1fba6f796c4a476f17eacddc#diff-7df2efc144fe15300a797d0a344ba324
I have looked at the coreboot code that Daniel brought to the picture and can see where the pmc_plt_clk_0 is referenced. As for the cyan chromebooks I can't see the code reference to the pmc_plt_clk_0. I'm sure that Sam is right in his argument, I just can't see the reference in the coreboot tree. The file devicetree.cb file shows the following under the sound header.
register "lpe_codec_clk_src" = "LPE_CLK_SRC_XTAL"
I don't really know where to go from here. The LPE_CLK_SRC_XTAL is present in ./soc/intel/braswell/chip.h and ./soc/intel/braswell/lpe.c as well as the devicetree.cb file. I just can't see where the pmc_plt_clk_0 is referenced. There is a
clk_reg = (u32 *) (PMC_BASE_ADDRESS + PLT_CLK_CTL_0);
which looks like it might be a hint for me. I am not sure what to do next. Perhaps a fresh set of eyes will help me look at this again tomorrow.
As to testing the patch, I have tried the kernel with CONFIG_SND_DMIC included and excluded with no difference. It does register the quirk, but does not help me get sound. I have reached out to Sam McNally for help, but he hasn't been available yet.
Chris
Wanted to update folks on my discoveries with this bug. First off, it is half fixed at least. I cannot get the internal microphone to pickup talking, but if you hit the mic, it registers. If I use a set of headphones with a microphone on them, the card captures voice. My hope is someone with more alsa experience than me may be able to get the laptop mic to record in the future. My thanks to Sam McNally and Matt DeVillier for their help while I tried to fix this issue on my laptop.