davidjo / snd_hda_macbookpro

Kernel audio driver for Macs with 8409 HDA chip + MAX98706/SSM3515 amps
GNU General Public License v2.0
288 stars 62 forks source link

No Microphone Input on MacBook Pro 13,1 (Linux Mint 21.1) #81

Open lbrunkho opened 1 year ago

lbrunkho commented 1 year ago

Hi, I would like to first say thanks for all the hard work on making this driver for us. I've been setting up a MacBook Pro 13,1 with Linux Mint 21.1 cinnamon and I am unable to get any audio input from the built-in microphone.

I was initially unable to get the driver to compile and kept getting the Hunk #3 FAILED at 328. error mentioned in #78. I was able to work around this by upgrading my kernel from the 5.15 branch to 5.19 and then installing gcc-12. After which the compile completed and I was able to get sound output to work.

The issue that I'm now facing is that cannot get the internal mic function correctly. It shows up in the Sound Settings but I cannot get the device to show any live levels and audacity will simply refuse to record this source.

If you would like, I can also try installing Ubuntu 22.04 to see if this is an issue with this particular flavor.

Thanks!

image

lbrunkho commented 1 year ago

Also here is the output of sudo journalctl | grep snd

Jan 17 15:13:29 Shiki kernel: snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
Jan 17 15:13:29 Shiki kernel: snd_hda_intel: Primary patch_cs8409
Jan 17 15:13:29 Shiki kernel: snd_hda_intel: Primary patch_cs8409 NOT FOUND trying APPLE
Jan 17 15:13:29 Shiki kernel: snd_hda_codec_cs8409 hdaudioC0D0: autoconfig for CS8409: line_outs=2 (0x24/0x25/0x0/0x0/0x0) type:speaker
Jan 17 15:13:29 Shiki kernel: snd_hda_codec_cs8409 hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
Jan 17 15:13:29 Shiki kernel: snd_hda_codec_cs8409 hdaudioC0D0:    hp_outs=1 (0x2c/0x0/0x0/0x0/0x0)
Jan 17 15:13:29 Shiki kernel: snd_hda_codec_cs8409 hdaudioC0D0:    mono: mono_out=0x0
Jan 17 15:13:29 Shiki kernel: snd_hda_codec_cs8409 hdaudioC0D0:    inputs:
Jan 17 15:13:29 Shiki kernel: snd_hda_codec_cs8409 hdaudioC0D0:      Internal Mic=0x44
Jan 17 15:13:29 Shiki kernel: snd_hda_codec_cs8409 hdaudioC0D0:      Mic=0x3c
Jan 17 15:13:29 Shiki kernel: snd_hda_codec_cs8409 hdaudioC0D0: cs_8409_cs42l83_jack_unsol_event UNSOL 0xdc000003 tag 0x37
Jan 17 15:13:29 Shiki kernel: snd_hda_codec_cs8409 hdaudioC0D0: cs_8409_cs42l83_unsolicited_response - NOT UNSOL BLOCKED
Jan 17 15:13:29 Shiki kernel: snd_hda_codec_cs8409 hdaudioC0D0: cs_8409_cs42l83_jack_unsol_event UNSOL 0xdc000002 tag 0x37
Jan 17 15:13:29 Shiki kernel: snd_hda_codec_cs8409 hdaudioC0D0: cs_8409_cs42l83_unsolicited_response - NOT UNSOL BLOCKED
Jan 17 15:13:29 Shiki kernel: snd_hda_codec_cs8409 hdaudioC0D0: cs_8409_cs42l83_jack_unsol_event UNSOL 0xdc000003 tag 0x37
Jan 17 15:13:29 Shiki kernel: snd_hda_codec_cs8409 hdaudioC0D0: cs_8409_cs42l83_unsolicited_response - NOT UNSOL BLOCKED
davidjo commented 1 year ago

I havent looked into the internal mike a lot. The last time I tried on my 14,3 machine I found the following behaviour. It appeared to be working but the sounds are at a very low level - so unless you add some audio path amplification you probably wouldnt hear anything (both alsa and pulse can do this). I was also using Audacity which I used for the mike testing. I recorded some sound directly ( I may also have had issues with Audacity recording directly cant remember now if it was just the low level) using arecord with the direct hardware device hw:0,0 (maybe could be the plughw device??) (just started arecord working then did some talking before stopping arecord which saved an audio file). Then loaded the file into Audacity. In Audacity I used one of its functions to amplify the audio - by a good deal - a factor of 256 seemed to be right - which I converted to dB and its something like 24db cant remember exactly now. When I played this in Audacity it had recorded what I had said. Currently I think this is the behaviour on Apple ie my coding is based on the commands sent to the 8409 so this level is what comes out of the 8409 device (the 8409 device is a very limited version of HDA chips and doesnt have internal amplifiers) and OSX then applies amplification at the CoreAudio level ie in the kernel. (Please note I really dont know a lot about the higher level audio paths in the Linux kernel - only what Ive learnt as part of attemping this kernel module).

Could you list the contents of your /etc/os-release here then can try and fix the script to handle Mint directly.

lbrunkho commented 1 year ago

My applogies for the delayed response, didn't see this notification until today.

Output of cat /etc/os-release

NAME="Linux Mint"
VERSION="21.1 (Vera)"
ID=linuxmint
ID_LIKE="ubuntu debian"
PRETTY_NAME="Linux Mint 21.1"
VERSION_ID="21.1"
HOME_URL="https://www.linuxmint.com/"
SUPPORT_URL="https://forums.linuxmint.com/"
BUG_REPORT_URL="http://linuxmint-troubleshooting-guide.readthedocs.io/en/latest/"
PRIVACY_POLICY_URL="https://www.linuxmint.com/"
VERSION_CODENAME=vera
UBUNTU_CODENAME=jammy

I did expect the level to be low (as mentioned in the readme) but audacity appeared to be unable to record off of this interface at all. Simply starting the record and then stopping like it was unable to open the device. I just tried again, pointing it directly to hw:0,0 I was able to get audacity to actually record. I washed the recording through the amplification filter twice and what I ended up with was a simple DC offset. No sound can be heard. image

I've never used arecord to record audio before but let me give it a shot and see what I can come up with.

lbrunkho commented 1 year ago

Got the same result with arecord.

$ arecord -d 10 -f cd -t wav -D hw:0,0 foobar.wav
Recording WAVE 'foobar.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo

After passing amplification twice I get a simple dc offset. image

davidjo commented 1 year ago

Thanks for the os-release dump.

Its not clear whats going on with the mike - I have some suspicion that there are differences between the various machine types using the 8409 based on various reports (which is a problem because the only way to sort that is to do a kernel log of the machine running OSX and using the mike). Its also quite likely that maybe some of the updates Ive done have messed with this as I havent re-tested the mike in a while. Ill see if I can try the mike out on my machine. Have to say I havent run an OSX mike log on my machine - but need to try and figure a good, simple OSX program that uses the mike.

lbrunkho commented 1 year ago

I actually have access to a MBP 13,3 that is running MacOS Big Sur. I was able to get a log of a Audacity launching and recording for a brief duration as well as the logs from the coreaudio service.

I obtained these logs by running the following command from MacOS terminal. sudo log show --predicate "processID == 744" --debug

MacBookPro13-3_audacity.log MacBookPro13-3_coreaudiod.log

Let me know if there is any other logging you want met to get from this system. I'm hoping that the differences between my 13,1 and 13,3 systems are negligible.

davidjo commented 1 year ago

Well just tried recording and didnt seem to work for me either so I think something has got messed up - have to see if I can boot an old OS (last time I did recording was in 2020) - I do have some old linux OSes on USB disks - and see whats changed.

Unfortunately the above logs dont go down far enough - I used an instrumented version of IOHDAFamily.kext (under AppleHDA.kext) - which annoyingly in previous OS versions was able to log HDA commands but Apple decided users shouldnt be able to do this.

lbrunkho commented 1 year ago

Gotcha, if I have time I will try to install an older version of MacOS and get those logs from the 13,3 system. @davidjo, do you remember what version of MacOS you needed to go back to get the logging of the HDA commands?

davidjo commented 1 year ago

Im still running HIgh Sierra - because thats the last OS before Apple started insisting on APFS - and at the time (and not sure even now) no linux drivers were available - I at least like to be able to cross-mount the filesystems even if only readonly. What I did was convert the IOHDAFamily.kext to compilable assembler and added kernel logging functions - which is how I discovered a stub kernel logging function in the code and hijacked that to be a proper kernel logger. So I have sent people the .ko extension (you could have the assembly code itself) if they are interested in doing a logging.

davidjo commented 1 year ago

I have just managed to restore a 5.4 system using Focal Fossa and can record directly in Audacity using commit 3274974c36f86c220bb11259e299d504e7958ba0.

Now to try and figure out how this got disabled.

davidjo commented 1 year ago

Have determined the issue but still not clear the best fix for this. I had to duplicate some hda_generic.c code for previous versions because there was a fixed dimension in hda_generic.c which was much too low for the 8409 chip - thought when the hda_generic.c dimension was updated could go back to the system coding but apparently not.

lbrunkho commented 1 year ago

Thanks for all work on this! If you need me to test out a specific commit or version of this driver, just @ me.

davidjo commented 1 year ago

@lbrunkho added replacement file for patch_cirrus_apple.h which should be fixed for internal mike recording. patch_cirrus_apple.h.log (rename it removing the .log - github wont upload source files) After running your base install just go into your build/hda-.... directory for your kernel kernel version and copy in this file. make clean; make then sudo make install will install new copies (you may need sudo for all of these if you ran the original install script with sudo). Probably should go into your /lib/modules/5.15...(whatever your version is) directory and perform sudo depmod -a then reboot. Ensure using your settings Sound page that the Input is set to Internal Microphone (updating the user side doesnt seem to be working properly yet). Then run Audacity and you should be able to record. The volume will be relatively low but the kernel driver cant fix this - needs to handled by user level ALSA/Pulse/Pipewire configuration. Also Im not sure how it will handle feedback if audio is playing - Ive just done recording with no speaker sound - Im pretty certain Apple is applying some DSP to sort this.

mattsays commented 1 year ago

Hi, I have just tried your new change, and it finally works my macbook pro 14,1 (arch linux kernel 6.1). Without this update I couldn't get any sound from microphone.

davidjo commented 1 year ago

Thanks for update will update the main repo soon.

lbrunkho commented 1 year ago

@davidjo sorry for the delayed response to you request. I've tested this on my 13,1 MacBook and it works!! As you mentioned, the audio levels are quite low but this is something that I can work with. For the record I was able to patch my existing system without the need to fresh install Linux Mint. Just moved in to the build folder for the correct kernel, downloaded the patch, and ran the make commands as root. I also went ahead and ran depmod -a in the /lib/modules folder (for me the full path was /lib/modules/5.19.0-28-generic/) and then rebooted.

Audacity works and I am able to get a decently clean signal. Screenshot below is +20dB gain and there is some background noise that is not from the Mic. image

Thanks again for all your work!

davidjo commented 1 year ago

Glad to know its working - there will likely be some noise issues at beginning (maybe end) as I think there some device buffer clearing issues which I havent tried to sort. You probably want to try and create a pseudo Alsa input sound device to include the amplication - either in the system /etc/asound.conf or user .asoundrc in your home directory (text files). But cant say Im an expert in Alsa configuration just played with it a bit. Will add this fixup to the main repo shortly.