Bug 110561
Node 0x1d is digital pin commplex which connected to digital output node 0x0a but driver put it in analog path You need to use hdajackretask to find out the real speaker pin from those unconnected pin complex Node 0x1d [Pin Complex] wcaps 0x406301: 8-Channels Digital Pincap 0x00000010: OUT Pin Default 0x90100110: [Fixed] Speaker at Int N/A Conn = Unknown, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Connection: 1 0x0a 6.971108] input: HDA Intel HDMI HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:03.0/sound/card0/input7 [ 6.985493] snd_hda_codec_cirrus hdaudioC1D0: autoconfig for CS4208: line_outs=1 (0x1d/0x0/0x0/0x0/0x0) type:speaker [ 6.985496] snd_hda_codec_cirrus hdaudioC1D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 6.985499] snd_hda_codec_cirrus hdaudioC1D0: hp_outs=1 (0x10/0x0/0x0/0x0/0x0) [ 6.985501] snd_hda_codec_cirrus hdaudioC1D0: mono: mono_out=0x0 [ 6.985502] snd_hda_codec_cirrus hdaudioC1D0: inputs: [ 6.985507] snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x19 [ 6.985511] snd_hda_codec_cirrus hdaudioC1D0: Mic=0x18 Node 0x10 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Line Out Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x42, nsteps=0x42, stepsize=0x03, mute=1 Amp-Out vals: [0x42 0x42] Pincap 0x0000001c: OUT HP Detect Pin Default 0x002b4020: [Jack] HP Out at Ext N/A Conn = Comb, Color = Green DefAssociation = 0x2, Sequence = 0x0 Pin-ctls: 0xc0: OUT HP Unsolicited: tag=01, enabled=1 Power states: D0 D3 EPSS Power: setting=D3, actual=D3 Connection: 1 0x02 Node 0x11 [Pin Complex] wcaps 0x400581: Stereo Pincap 0x00000054: OUT Detect Balanced Pin Default 0x400000f0: [N/A] Line Out at Ext N/A Conn = Unknown, Color = Unknown DefAssociation = 0xf, Sequence = 0x0 Pin-ctls: 0x00: Unsolicited: tag=00, enabled=0 Power states: D0 D3 EPSS Power: setting=D3, actual=D3 Connection: 1 0x02 Node 0x12 [Pin Complex] wcaps 0x400501: Stereo Pincap 0x00000050: OUT Balanced Pin Default 0x400000f0: [N/A] Line Out at Ext N/A Conn = Unknown, Color = Unknown DefAssociation = 0xf, Sequence = 0x0 Pin-ctls: 0x00: Power states: D0 D3 EPSS Power: setting=D3, actual=D3 Connection: 1 0x03 Node 0x13 [Pin Complex] wcaps 0x400501: Stereo Pincap 0x00000050: OUT Balanced Pin Default 0x400000f0: [N/A] Line Out at Ext N/A Conn = Unknown, Color = Unknown DefAssociation = 0xf, Sequence = 0x0 Pin-ctls: 0x00: Power states: D0 D3 EPSS Power: setting=D3, actual=D3 Connection: 1 0x04 Node 0x14 [Pin Complex] wcaps 0x400501: Stereo Pincap 0x00000050: OUT Balanced Pin Default 0x400000f0: [N/A] Line Out at Ext N/A Conn = Unknown, Color = Unknown DefAssociation = 0xf, Sequence = 0x0 Pin-ctls: 0x00: Power states: D0 D3 EPSS Power: setting=D3, actual=D3 Connection: 1 0x05 if (cfg->speaker_outs >= ARRAY_SIZE(cfg->speaker_pins)) {
codec_info(codec,
"ignore pin 0x%x, too many assigned pins\n",
nid);
continue;
}
+ if (get_wcaps(codec, nid) & AC_WCAP_DIGITAL) {
+ codec_info(codec, "ignore pin 0x%x, digital wcaps\n", nid);
+ continue;
+ }
speaker_out[cfg->speaker_outs].pin = nid;
speaker_out[cfg->speaker_outs].seq = (assoc << 4) | seq;
cfg->speaker_outs++;
break;
I've added your patch, and have posted the output of alsa-info.sh (without having configured any unconnected pins). I've tried a few different combinations of configuring the unconnected pins, but with no success. I need to know what the best practices are when using hdajackretask. I've gone one by one, from pin 0x10 to 0x14 and clicking override, selecting internal speaker {default, LFE, back}, installing boot override and rebooting. Setting some pins will disable the internal speaker completely (according to pulse audio). I've also tried selecting internal speaker for all 3,4, and 5 different pins at the same time. I could use some direction though. Let me know what configurations/logs you would find the most useful.
Created attachment 199481 [details] alsa-info.sh output (w/ patch comment #3) seem segfault in your system log [ 572.640000] do not call blocking ops when !TASK_RUNNING; state=2 set at [<ffffffff810fc960>] prepare_to_wait_event 0x60/0xf0 [ 572.640003] Modules linked in: intel_rapl iosf_mbi x86_pkg_temp_thermal nls_utf8 coretemp hfsplus iTCO_wdt kvm_intel iTCO_vendor_support kvm irqbypass crct10dif_pclmul crc32_pclmul applesmc input_polldev joydev brcmfmac brcmutil cfg80211 snd_hda_codec_cirrus snd_hda_codec_generic snd_hda_codec_hdmi mmc_core pcspkr i2c_i801 rfkill intel_pch_thermal snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep sbs sbshc snd_seq acpi_als snd_seq_device kfifo_buf industrialio snd_pcm mei_me spi_pxa2xx_platform apple_bl mei snd_timer snd lpc_ich tpm_tis soundcore tpm shpchp btrfs xor raid6_pq r8152 mii i915 crc32c_intel i2c_algo_bit drm_kms_helper nvme drm video fjes [ 572.640099] CPU: 3 PID: 794 Comm: wpa_supplicant Tainted: G W 4.4.0-macbook.fc23.x86_64 #1 The patch only ignore the incorrect digital pin node 0x10 from the analog path how many speakers do you have since there are four [Audio Output] ? Try node 0x12, 0x13 or 0x14 since node 0x11 share volume control [Audio Output] 0x02 with headphone You can use hdajacksensetest to verify node 0x10 is headphone when you olug and unplug the headphone Node 0x02 [Audio Output] wcaps 0xd043d: Stereo Amp-Out Stripe Control: name="Line Out Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Device: name="CS4208 Analog", type="Audio", device=0 Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x01, mute=1 Amp-Out vals: [0x7f 0x7f] Converter: stream=5, channel=0 PCM: rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000 bits [0x1e]: 16 20 24 32 formats [0x3]: PCM FLOAT Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Delay: 13 samples Node 0x03 [Audio Output] wcaps 0xd043d: Stereo Amp-Out Stripe Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x01, mute=1 Amp-Out vals: [0xff 0xff] Converter: stream=0, channel=0 PCM: rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000 bits [0x1e]: 16 20 24 32 formats [0x3]: PCM FLOAT Power states: D0 D3 EPSS Power: setting=D3, actual=D3 Delay: 13 samples Node 0x04 [Audio Output] wcaps 0xd043d: Stereo Amp-Out Stripe Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x01, mute=1 Amp-Out vals: [0xff 0xff] Converter: stream=0, channel=0 PCM: rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000 bits [0x1e]: 16 20 24 32 formats [0x3]: PCM FLOAT Power states: D0 D3 EPSS Power: setting=D3, actual=D3 Delay: 13 samples Node 0x05 [Audio Output] wcaps 0xd043d: Stereo Amp-Out Stripe Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x01, mute=1 Amp-Out vals: [0xff 0xff] Converter: stream=0, channel=0 PCM: rates [0x7f0]: 32000 44100 48000 88200 96000 176400 192000 bits [0x1e]: 16 20 24 32 formats [0x3]: PCM FLOAT Power states: D0 D3 EPSS Power: setting=D3, actual=D3 Delay: 13 samples Created attachment 199531 [details]
image-speakers
I'll perform some more testing when I get home. In the meantime, I've found an image of the speakers in this laptop.
0x10 is definitely the headphone jack. I've tried setting 0x12, 0x13 or 0x14 and other various combinations. I've made sure every source was unmuted in alsamixer. Is there a way to set 0x02, 0x03, 0x04, and 0x05? I don't see those with hdajackretask. I could always reinstall OSX on the laptop if it would help us gather any useful information regarding the audio configuration. You likely need to pass a proper pin configuration *in addition* to GPIO0 workaround. BTW, how did you try model option? Since Cirrus codec is the secondary one, you'd have to pass like "model=,mba6" -- note the comma before "mba6". For CS4208, you can try either mba6, mbp11 or gpio0 model. If any or them are really not working, keep "model=,gpio0" and try to figure out the pin configuration. I'll try start trying now. Can't I just pass index=1 to reference the 2nd card? Yes it would work, too. I see the difference --if I use index=1, it changes the PCH device to card 0. I'll stick with your method to keep the order consistent. I've tried model=,mba6 and model=,mbp11. With model=,gpio0 I'm a bit out of my depth. Can you just give me a basic run down of how to set a pin configuration? I figured it out.... It looks like 0x12 is definitely a speaker. The default value 0x90170150 for internal speaker doesn't work. I just need to find the right value to modify user_pin_configs with. Based on what I've seen in patch_cirrus.c --the value I'm looking for should be 0x90100010XXX Bit 8 of pin default should be set as internal speaker does not support Jack detection https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/patch_cirrus.c?id=b5bf0a929d7ca35b9ccfc24647a397899d307659 Created attachment 199771 [details]
win-gpio-controls
After I modified user_pin_configs, I tried echo 1 > reconfig to get the configuration to take --but I always receive the message "echo: write error: Device or resource busy". I've tried disabling pulseaudio, running alsactl nrestore...etc --but to no avail. I could use some advice on how to do this. In the meantime, I've loaded windows on the laptop, and have run High Definition Audio tool. Windows shows the playback device as "Digital Speaker Amplifier". I'm uploading a couple screenshots from the audio tool. If you have used this tool before, let me know what information you would find most useful.
Created attachment 199781 [details]
0x1d Pin Configuration
device 0x1d is apparently used as the output device.
Created attachment 199841 [details]
cs4208_24.inf
This is the windows driver file.
Not sure if this is important, but both playback devices (headphones + digital speaker amplifier) show that they are of device type Cirrus Logic CS4208 (AB 100)
Use "set as boot default" instead of dynamic reconfigurstion since you have top stop all applications to use the sound card, e.g. disable pulseaudio auto spwan Codec: Cirrus Logic CS4208 Address: 0 AFG Function Id: 0x1 (unsol 1) Vendor Id: 0x10134208 Subsystem Id: 0x106b6400 Revision Id: 0x100401 Using hda emu to compare those verbs used by alsa driver and windows Created attachment 201311 [details]
codec-graph
I've posted the output of codecgraph
# ./codecgraph /proc/asound/card1/codec#0
Codec: Cirrus Logic CS4208
Node 0x06: Amp-In vals count is wrong: values found: 3. expected: 1
Node 0x07: Amp-In vals count is wrong: values found: 3. expected: 1
If NID 0x12 is the speaker, the firmware patch below may work. Crrete a file /lib/firmware/alsa/mb81 containing the following: [codec] 0x10134208 0x106b6400 0 [pincfg] 0x10 0x002b4020 0x12 0x90100120 0x18 0x00ab9030 0x19 0x90a60100 # [hint] # inv_jack_detect = true Then pass it via patch module option, e.g. put the following to /etc/modprobe.d/50-alsa-hda.conf containing: options snd-hda-intel patch=,alsa/mb81 Note that the comma before "alsa/mb81". It means the secondary card entry. You may notice that the last two lines of the firmware patch are commented out. In case the jack detection is inverted, try to enable these lines. If the above still doesn't work, take alsa-info.sh output at the headphone plugged and unplugged states, and upload to Bugzilla for further analysis. Created attachment 202791 [details]
alsa-info.sh w/ mba81 patch h/p unplugged
alas-info.sh output w/ mba81 firmware patch. Headphones unplugged.
No sound from speakers. **didn't need to apply inverse_jack_detect.
Created attachment 202801 [details]
alsa-info.sh w/ mba81 patch h/p plugged in
alas-info.sh output w/ mba81 firmware patch. Headphones plugged in and audio is coming through.
You need to fixup node 0x1d, hda_auto_parser place digial pin in analog path Node 0x0a [Audio Output] wcaps 0x46631: 8-Channels Digital Stripe Device: name="CS4208 Analog", type="Audio", device=0 Converter: stream=5, channel=0 Digital: Enabled Non-Copyright Digital category: 0x1 IEC Coding Type: 0x0 PCM: rates [0x60]: 44100 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Delay: 4 samples Node 0x1d [Pin Complex] wcaps 0x406301: 8-Channels Digital Pincap 0x00000010: OUT Pin Default 0x90100110: [Fixed] Speaker at Int N/A Conn = Unknown, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Connection: 1 0x0a snd_hda_codec_cirrus hdaudioC1D0: autoconfig for CS4208: line_outs=2 (0x1d/0x12/0x0/0x0/0x0) type:speaker snd_hda_codec_cirrus hdaudioC1D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) snd_hda_codec_cirrus hdaudioC1D0: hp_outs=1 (0x10/0x0/0x0/0x0/0x0) snd_hda_codec_cirrus hdaudioC1D0: mono: mono_out=0x0 snd_hda_codec_cirrus hdaudioC1D0: inputs: snd_hda_codec_cirrus hdaudioC1D0: Internal Mic=0x19 snd_hda_codec_cirrus hdaudioC1D0: Mic=0x18 Right, it was missing. Judging from alsa-info.sh output, the HP jack sensing looks working normally. So inv_jack_detect things can be dropped. So it'll be like: [codec] 0x10134208 0x106b6400 0 [pincfg] 0x10 0x002b4020 0x12 0x90100120 0x18 0x00ab9030 0x19 0x90a60100 0x1d 0x400000f0 If this still doesn't work, please give alsa-info.sh outputs again at both HP plugged and unplugged. Created attachment 202811 [details]
alsa-info.sh w/ mba81 v2 patch hp unplugged
alsa-info.sh
*no audio internal speakers
Created attachment 202821 [details]
alsa-info.sh w/ mba81 v2 patch hp plugged-in
alsa-info.sh
*headphone audio working
Hello hello. I just tested with 4.6rc3 on a ubuntu 16.04 an the issue is still there :( What is surprising is that the sound in (MIC) is working fine! If I can help with traces. Pls let me know derarnold P.s. Perhaps it is an ALSA issue and not a kernel issue ... Created attachment 258651 [details]
alsa-info-macbookair6,1 (for comparison)
Created attachment 258653 [details]
macbook9,1 alsa-info.sh
macbook9,1 (2016) model
the macbookair6,1 and 6,2 has a really similar config to that of the macbook8,1 + 9,1 this shows what the init pin config of the macbookair6,1 looks like, compared to that which the patch_cirrus driver has modified. init_pin_configs modified (driver) pin_configs 0x10 0x002b4020 0x10 0x032120f0 #stereo Amp-Out #HP 0x11 0x400000f0 0x11 0x500000f0 #stereo 0x12 0x90100110 0x12 0x90100010 #stereo #Speaker 0x13 0x400000f0 0x13 0x500000f0 #stereo 0x14 0x400000f0 0x14 0x500000f0 #stereo 0x15 0x400000f0 0x15 0x770000f0 #Stereo Amp-In 0x16 0x400000f0 0x16 0x770000f0 #Stereo Amp-In 0x17 0x400000f0 0x17 0x430000f0 #Stereo Amp-In 0x18 0x00ab9030 0x18 0x43ab9030 #Mono Amp-In 0x19 0x400000f0 0x19 0x770000f0 #Stereo Amp-In 0x1a 0x400000f0 0x1a 0x770000f0 #Stereo Amp-In 0x1b 0x400000f0 0x1b 0x770000f0 #Stereo Amp-In 0x1c 0x90a60100 0x1c 0x90a00090 #Stereo Amp-In #Int Mic 0x1d 0x400000f0 0x1d 0x500000f0 #8-Channels Digital 0x1e 0x400000f0 0x1e 0x500000f0 #8-Channels Digital 0x1f 0x400000f0 0x1f 0x500000f0 #8-Channels Digital 0x20 0x400000f0 0x20 0x500000f0 #8-Channels Digital 0x21 0x400000f0 0x21 0x430000f0 #Stereo Digital 0x22 0x400000f0 0x22 0x430000f0 #Stereo Digital Pin-ctrls: HP: 0xc0 Speaker: 0x40 Int Mic: 0x20 this is that the default config looks like for the macbook9,1 0x10 0x002b4020 #stereo amp-out #HP 0x11 0x400000f0 #stereo 0x12 0x400000f0 #stereo 0x13 0x400000f0 #stereo 0x14 0x400000f0 #stereo 0x15 0x400000f0 #stereo Amp-In 0x16 0x400000f0 #stereo Amp-In 0x17 0x400000f0 #stereo Amp-In 0x18 0x00ab9030 #mono Amp-In #Mic Jack 0x19 0x90a60100 #Stereo Amp-In #internal Mic 0x1a 0x400000f0 #stereo Amp-In 0x1b 0x400000f0 #stereo Amp-In 0x1c 0x400000f0 #stereo Amp-In 0x1d 0x90100110 #8-Channels Digital #speaker 0x1e 0x400000f0 #8-Channels Digital 0x1f 0x400000f0 #8-Channels Digital 0x20 0x400000f0 #8-Channels Digital 0x21 0x400000f0 #stereo digital 0x22 0x400000f0 #stereo digital Pin-ctrls: HP: 0xc0 Speaker: 0x40 Mic Jack: 0x24 Int Mic: 0x20 on the macbook9,1 headphone output works, microphone works. Just need to get the speakers to work.
this is current I'm trying out (modifying patch_cirrus and rebooting). Aside from a few minor touch ups, the main change is assigning 0x12 the speaker role.
0x10 0x042b20f0 #stereo amp-out #HP
0x11 0x500000f0 #stereo
0x12 0x90100010 #stereo #speaker
0x13 0x500000f0 #stereo
0x14 0x500000f0 #stereo
0x15 0x770000f0 #stereo Amp-In
0x16 0x770000f0 #stereo Amp-In
0x17 0x430000f0 #stereo Amp-In
0x18 0x04ab2050 #mono Amp-In #Mic Jack
0x19 0x90a00070 #stereo Amp-In #internal Mic
0x1a 0x770000f0 #stereo Amp-In
0x1b 0x770000f0 #stereo Amp-In
0x1c 0x770000f0 #stereo Amp-In
0x1d 0x500000f0 #8-Channels Digital
0x1e 0x500000f0 #8-Channels Digital
0x1f 0x500000f0 #8-Channels Digital
0x20 0x500000f0 #8-Channels Digital
0x21 0x430000f0 #stereo digital
0x22 0x430000f0 #stereo digital
However, 0x1d is still using pin-ctrl 0x40
So, I've run these commands to assign 0x12 pin-ctrl 0x40
hda-verb /dev/snd/hwC0D0 0x1d SET_PIN_WIDGET_CONTROL 0
hda-verb /dev/snd/hwC0D0 0x12 SET_PIN_WIDGET_CONTROL 0x40
the issue is that 0x12 has transitioned to a D0 power state with this config:
Node 0x12 [Pin Complex] wcaps 0x400501: Stereo
Pincap 0x00000050: OUT Balanced
Pin Default 0x400000f0: [N/A] Line Out at Ext N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x40: OUT
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Connection: 1
0x03
Does anyone know how I can power on 0x12?
Created attachment 258655 [details]
cs4208_27.inf (windows driver)
**in case anybody understands how to read this
macbook8,1
HdAudioFunctionDriver.CS4208_106B6400.DeviceDesc = "Cirrus Logic CS4208 (AB 100)"
macbook9,1
HdAudioFunctionDriver.CS4208_106B6500.DeviceDesc = "Cirrus Logic CS4208 (AB 101)"
Created attachment 258657 [details]
HDAudio.Cirrus_CONF_0807
The macbook9,1 (and 8,1) uses the HDAudio.Cirrus_CONF_0807 configuration. I've extracted the CONF_0807 configuration bits from inf file, so you don't have to trawl through it. Even, thought the macbook9,1 and macbookair6.x uses the same codec, a Cirrus Logic CS4208, the underlying configuration is quite different.
this document lists the initverbs, pinconfig override verbs...etc
what's odd, is this document references an SpdifOut, but this macbook doesn't have an physical spdif port as part of the headphone jack. so, it must be using that internally. If anyone can help decode this document, it would be extremely helpful. Even if it's something as simple as explaining what TDMQuadTopo means.
I've used the HDA audio tool on windows to analyze the configuration in a bit more in depth. This is the exact pin configuration windows uses: 0x10 0x042b20f0 #stereo amp-out #HP jack 0x11 0x500000f0 #stereo 0x12 0x500000f0 #stereo 0x13 0x500000f0 #stereo 0x14 0x500000f0 #stereo 0x15 0x770000f0 #stereo Amp-In 0x16 0x770000f0 #stereo Amp-In 0x17 0x430000f0 #stereo Amp-In 0x18 0x04ab2050 #mono Amp-In #Mic Jack 0x19 0x90a00070 #stereo Amp-In #internal Mic 0x1a 0x770000f0 #stereo Amp-In 0x1b 0x770000f0 #stereo Amp-In 0x1c 0x770000f0 #stereo Amp-In 0x1d 0x90400010 #8-Channels Digital #digital speaker amplifier 0x1e 0x500000f0 #8-Channels Digital 0x1f 0x500000f0 #8-Channels Digital 0x20 0x500000f0 #8-Channels Digital 0x21 0x430000f0 #stereo digital 0x22 0x430000f0 #stereo digital **windows shows the output device as a 'Digital Speaker Amplifier', the volume control is marked as digital output/spdif **in Linux (with this pin configuration), the analog speaker output is seen as unplugged. I believe the digital stereo (IEC958) output profile needs to be used with this setup. alsamixer shows 7 SPDIF items: S/PDIF S/PDIF Default PCM S/PDIF 1 S/PDIF 2 S/PDIF 3 S/PDIF 4 S/PDIF 16 has anyone else come across an all digital audio setup like this before? **I would like to test with just ALSA, however it seems that ALSA is dependent upon pulseaudio running. Created attachment 258677 [details]
init-verbs and pin-config-overrides
I've translated the init verbs and pin-config-overrides to hda-verb commands. I just kind of worked out of to translate the values in the windows registry --based on the values I saw in patch_cirrus.c. It's possible I made some mistakes...
**the most interesting lines are:
#CIR=04h, coeff=0C04h (TX1 ch 0: slot 4, ch 1: slot 12)
hda-verb /dev/snd/hwC0D0 0X24 0X500 0X04
hda-verb /dev/snd/hwC0D0 0X24 0X40C 0X04
#CIR=05h, coeff=1000h (TX1 ch 2: slot 0, ch 3: slot 16)
hda-verb /dev/snd/hwC0D0 0X24 0X500 0X05
hda-verb /dev/snd/hwC0D0 0X24 0X410 0X00
#TX1: ASSN=1h, SEQ=0h COL=unkn DD=SPDO, CTYP=unkn PCON=fixed, LOC=int
hda-verb /dev/snd/hwC0D0 0x1d 0x71c 0x10
hda-verb /dev/snd/hwC0D0 0x1d 0x71d 0x00
hda-verb /dev/snd/hwC0D0 0x1d 0x71e 0x40
hda-verb /dev/snd/hwC0D0 0x1d 0x71f 0x90
**not sure how to translate the GPIO values Gpio0ExtAmpCfg, 0A,00,00,01 #GPIO0 is an output controlled by TX1 PS-Set Gpio4ExtAmpCfg, 01,00,00,01 #GPIO4 is an output controlled by AFG PS-Set (to HS3 DFET) Gpio5ExtAmpCfg 01,00,00,01 #GPIO5 is an output controlled by AFG PS-Set (to HS4 DFET) **although, I don't think anything needs to been done GPIO0, that fixup already exists in patch_cirrus.c The (windows) HDA audio tool did show a gpio mask and dir values of 0x31 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x31 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x31 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0 Created attachment 258681 [details]
init-verbs and pin-config-overrides v2
**fixed errors with AC_VERB_SET_PROC_COEF values.
static const struct hda_verb cs4208_coef_init_verbs[] = {
{0x01, AC_VERB_SET_POWER_STATE, 0x00}, /* AFG: D0 */
{0x24, AC_VERB_SET_PROC_STATE, 0x01}, /* VPW: processing on */
{0x24, AC_VERB_SET_COEF_INDEX, 0x0000},
{0x24, AC_VERB_SET_PROC_COEF, 0x0080}, //SPCC = 10b, SP1M = 0b//
{0x24, AC_VERB_SET_COEF_INDEX, 0x0004},
{0x24, AC_VERB_SET_PROC_COEF, 0x0C04}, /*TX1 ch0: slot4, ch1: slot12 */
{0x24, AC_VERB_SET_COEF_INDEX, 0x0005},
{0x24, AC_VERB_SET_PROC_COEF, 0x1000}, /*TX1 ch2: slot0, ch3: slot16 */
{0x24, AC_VERB_SET_COEF_INDEX, 0x001D},
{0x24, AC_VERB_SET_PROC_COEF, 0x0BF6}, //DC detect level = 36h//
{0x24, AC_VERB_SET_COEF_INDEX, 0x0033},
{0x24, AC_VERB_SET_PROC_COEF, 0x4493}, //A/CGat, A2/CInv, A1/A2/C ICS//
{0x24, AC_VERB_SET_COEF_INDEX, 0x0034},
{0x24, AC_VERB_SET_PROC_COEF, 0x1B13}, /* A1 Enable, A Thresh=250mV */
{0x24, AC_VERB_SET_COEF_INDEX, 0x0050},
{0x24, AC_VERB_SET_PROC_COEF, 0x008B}, //jack sense hysteresis //
{0x24, AC_VERB_SET_COEF_INDEX, 0x0040},
{0x24, AC_VERB_SET_PROC_COEF, 0x9999}, //VPW: test mode on//
{} /* terminator */
};
I've modified this data structure in patch_cirrus.c to use the init verbs found in the windows driver. I could use some guidance at this point. I think I'm on the right path, but it hard to know for sure, since the sound still isn't working.
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x31 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x31 hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x0 #running these commands enables GPIO4 + 5 "comment 42" GPIO: io=6, o=2, i=0, unsolicited=1, wake=1 IO[0]: enable=1, dir=1, wake=0, sticky=0, data=0, unsol=0 IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[3]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[4]: enable=1, dir=1, wake=0, sticky=0, data=0, unsol=0 IO[5]: enable=1, dir=1, wake=0, sticky=0, data=0, unsol=0 Created attachment 258687 [details] alsa-info.sh (with init verbs + pin config patch) This is the alsa-info.sh output using the pin configs from "comment 40", the cs4208_coef_init_verbs from "comment 44", and the hda-verb commands from "comment 42" **I think we may have a SPDIF (IEC958) mixing issue. node 0x0a is the DAC audio output that feeds node 0x1d "digital amplifier?" there may be something off with the way the audio is being routed there are some definite improvements: original alsa-info.sh: Node 0x0a [Audio Output] wcaps 0x46631: 8-Channels Digital Stripe Converter: stream=5, channel=0 Digital: Enabled Non-Copyright Digital category: 0x1 IEC Coding Type: 0x0 PCM: rates [0x60]: 44100 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Delay: 4 samples new alsa-info.sh: Node 0x0a [Audio Output] wcaps 0x46631: 8-Channels Digital Stripe Control: name="IEC958 Playback Con Mask", index=16, device=0 Control: name="IEC958 Playback Pro Mask", index=16, device=0 Control: name="IEC958 Playback Default", index=16, device=0 Control: name="IEC958 Playback Switch", index=16, device=0 Control: name="IEC958 Default PCM Playback Switch", index=0, device=0 Device: name="CS4208 Digital", type="SPDIF", device=1 Converter: stream=1, channel=0 Digital: Enabled GenLevel Digital category: 0x2 IEC Coding Type: 0x0 PCM: rates [0x60]: 44100 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D3 EPSS Power: setting=D0, actual=D0 Delay: 4 samples the (windows) hda audio tool shows that: Node 0x0a has a wcaps value of 0x42631 while Linux reports a value of 0x46631 **this is the only wcaps value that differs If I'm understand this correctly, the difference is that a wcaps value of 0x42631 indicates a channel count value of 0x4 while a wcaps value of 0x46631 indicates a channel count value of 0x8 That seems a bit odd to say the least, I'd like to change this value in Linux but have no idea how to do it. Does anyone have any ideas? [root@mac ~]# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: PCH [HDA Intel PCH], device 0: CS4208 Analog [CS4208 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 1: CS4208 Digital [CS4208 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 ... Created attachment 258691 [details]
amixer -c0 output
amixer -c0 output
shows 7 seperate mixer controls for IEC958
HKR,cs420x,n0AWidgetCaps 0x00042631 ; TX1: override widget caps: CCE=1 HKR,cs420x,n0ASuppBitsRates 0x000E0040 ; TX1: override rate caps: -R6 Regarding the Node 0x0a wcaps issue, I found these two lines in the windows driver file. Can someone tell me how to perform the equivalent operation with Linux? I added this code to patch_cirrus.c to override the wcaps value for node 0x0a and set it to 0x42631 (271921 decimal)
chans = get_wcaps(codec, 0x0a);
chans = get_wcaps_channels(chans);
printk("0x0a chans is %u\n", chans);
snd_hda_override_wcaps(codec, 0x0a, 271921);
printk("0x0a wcaps is %u\n", get_wcaps(codec, 0x0a));
chans = get_wcaps(codec, 0x0a);
chans = get_wcaps_channels(chans);
printk("0x0a chans is %u\n", chans);
dmesg shows that it did change the wcaps value and the channel count did change from 8 to 4, exactly what I wanted it to do!
[ 5.874826] 0x0a chans is 8
[ 5.874827] 0x0a wcaps is 271921
[ 5.874827] 0x0a chans is 4
However, when I cat out codec#0, I find the original wcaps value:
# cat /proc/asound/card0/codec#0 | grep 'Node 0x0a'
Node 0x0a [Audio Output] wcaps 0x46631: 8-Channels Digital Stripe
There are existing wcap override statements in patch_cirrus.c, such as:
snd_hda_override_wcaps(codec, 0x18,
get_wcaps(codec, 0x18) | AC_WCAP_STEREO);
/proc/asound/card0/codec#0 does not show the modified wcaps value for 0x18.
So either 'snd_hda_override_wcaps' doesn't work or /proc/asound/card0/codec#0 doesn't show modified wcaps values.
It doesn't looks like 'snd_hda_override_wcaps' works correctly (or I'm using it wrong). # hda-verb /dev/snd/hwC0D0 0x0a 0xf00 0x09 nid = 0xa, verb = 0xf00, param = 0x9 value = 0x46631 The function changes the cached value in the driver and doesn't actually change the value read from the codec (you can't change -- it's a read-only). That's why the value shown in the proc file doesn't change after overriding it. Created attachment 260291 [details]
patch_cirrus.c patch
this is a work-in-progress patch. It contains the correct pin configuration, gpio mask, and wcaps value for node 0x0a. I've also overridden cs4208_coef_init_verbs to match the init verbs listed in the windows driver.
I need to sort out how to do the following:
the windows driver contains this line:
HKR,cs420x,n0ASuppBitsRates,%REG_DWORD%, 0x000E0040; TX1: override rate caps: -R6
**what is means is that node 0x0a only supports PCM rates of 48000
The value linux has is 0xe0060
hda-verb /dev/snd/hwC0D0 0x0a 0xf00 0xa
nid = 0xa, verb = 0xf00, param = 0xa
value = 0xe0060
** 0xe0060 corresponds to PCM rates: 44100 and 48000
Node 0x0a
....
PCM:
rates [0x60]: 44100 48000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Does anyone know how I can set the supported PCM rate to 48000?
Instead of fiddling with the PCM capability bits override, you can limit the rates to be used by overriding the PCM rates bits in hda_pcm_stream definition. See alc269_fixup_pcm_44k() in patch_realtek.c as an example. thanks! I'll check it out. If you look at the patch I've just posted, you'll see the following init verbs:
{0x24, AC_VERB_SET_COEF_INDEX, 0x0004},
{0x24, AC_VERB_SET_PROC_COEF, 0x0C04}, /*TX1 ch 0: slot 4, ch 1: slot 12 */
{0x24, AC_VERB_SET_COEF_INDEX, 0x0005},
{0x24, AC_VERB_SET_PROC_COEF, 0x1000}, /*TX1 ch 2: slot 0, ch 3: slot 16 */
TX1 --corresponds to node 0x1d, which is the digital speaker amplifier.
the following is found in in the windows driver:
;; Set default format to 48kHz, 24-bit, Quad
...
HKLM,"Software\\Cirrus\\APO\\FilterAPO","APOProcessMode",0x00010001,0x2 ; quad (FL/FR - woofers, RL/RR - tweeters)
I'm guessing each TX1 channel listed above: 0,1,2,3 corresponds to one of these four speakers: FL/FR and RL/RR.
**perhaps, this is why the channel count was changed to 4 for node 0x0a, see comment 51
**node 0x0a is the DAC audio output that feeds node 0x1d
I'm not sure how these init verbs are supposed to function, or how to verify they are working correctly. Shouldn't these init verbs bring these speakers online, what else needs to be done?
It doesn't look like the mixer controls are set up properly for this configuration.
the audio needs to be routed through card 0, device 1
card 0: PCH [HDA Intel PCH], device 1: CS4208 Digital [CS4208 Digital]
I have no idea on how adjust the mixer controls, and I'm a bit out of my depth here, if anyone has any ideas --please share them.
Not sure if this is significant or not, but windows returns a different response then linux to the F0D verb (S/PDIF Converter Control) windows: 0x00800215 linux: 0x111 the main differences are that windows has the VCFG (validity config) and KAE (keep alive enable) bits enabled. Does anyone know how I could enable these bits in Linux (or perform an equivalent operation)? ..I sorted out how to change those bits: hda-verb /dev/snd/hwC0D0 0x0a 0x70d 0x15 hda-verb /dev/snd/hwC0D0 0x0a 0x73e 0x80 **simple method to cycle through all 64 coefficient indexes and retrieve the processing coefficient values. #!/bin/bash cmd='hda-verb /dev/snd/hwC0D0 0x24' $cmd SET_COEF_INDEX 0x0 &> /dev/null while true; do index=$($cmd GET_COEF_INDEX 0 2>/dev/null | sed 's/value/index/') value=$($cmd GET_PROC_COEF 0 2>/dev/null) echo -e "$index\n$value" [[ $index -eq '0x3f' ]] && break done **output index = 0x0 value = 0x80 index = 0x1 value = 0x0 index = 0x2 value = 0x3a index = 0x3 value = 0xbaa index = 0x4 value = 0xc04 index = 0x5 value = 0x1000 ... Created attachment 260387 [details]
patch_cirrus.c patch v2
work-in-progress patch
Created attachment 260413 [details]
window-sound-device-screenshots
Created attachment 260415 [details] hda-tool-pin-out windows hda-tool pinout. Useful tool, unfortunately I'm not able to send verbs to extract current info. Receive error "Unable to execute verb. Only pin configurations can be set without the chk driver". I barely know how to use windows. Does anyone know how I can execute verbs on windows? This link looks promising: https://docs.microsoft.com/en-us/windows-hardware/drivers/audio/communicating-verbs-with-the-hd-audio-codec I'm not sure what language this is written in (c++ ??). Anyways..if anyone's got any experience in this area please let me know. I'm particularly interested in sorting out whether any of the coefficient values in the vendor widget change in response to certain actions. here's an example of where a coefficient value affects amp gain: "/* Speaker Amp Gain is controlled by the vendor widget's coef 4 */" https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_cirrus.c#L943 Back to square one...
I managed to hda-verb working on OSX! Here's what I've learned so far.
The vendor coefficients don't need to be modified in Linux. The default values are correct. There were 3 coefficients near the end of the list that were different in OSX. However, changing these in Linux didn't have any effect.
The pin configuration doesn't need to be modified.
The GPIO config in OSX, looks like:
headphones unplugged headphones plugged-in
gpio mask --> 0x37 gpio mask --> 0x37
gpio dir --> 0x31 gpio dir --> 0x31
gpio data --> 0x7 gpio data --> 0x6
**GPIO0 powers the speakers. Interestingly enough, none of the GPIO pins power the headphone jack. I can't believe I never tested that before.
**digital converter value is 0x111 in OSX
hda-verb 0x0a 0xF0D 0 = 0x111
There were a few other insignificant changes, but that's basically it.
Is there a way to view this Control information in OSX (or something similar)?
ie
Control: name="Line Out Playback Volume", index=0, device=0
ControlAmp: chs=3, dir=Out, idx=0, ofs=0
I'm wondering if there should be an amp controlled by node 0x0a
Node 0x0a [Audio Output] wcaps 0x46631: 8-Channels Digital Stripe
Control: name="IEC958 Playback Con Mask", index=16, device=0
Control: name="IEC958 Playback Pro Mask", index=16, device=0
Control: name="IEC958 Playback Default", index=16, device=0
Control: name="IEC958 Playback Switch", index=16, device=0
Device: name="CS4208 Digital", type="SPDIF", device=1
The one thing missing from this is output (besides possibly an amp) is:
'Control: name="IEC958 Default PCM Playback Switch", index=0, device=0'
Why doesn't node 0x0a have a Default PCM Playback Switch? Nothing is controlling that output.
Created attachment 260427 [details]
hda-verb results Linux + OSX
ran a full battery of hda-verbs on Linux and OSX. These are the results. I've removed lines where the result was 0x0. The left column show Linux results, the right column shows any differing OSX results.
comment 65 my mistake: Control: name="IEC958 Default PCM Playback Switch", index=0, device=0 does show up in the 'cat /proc/asound/card0/codec#0' output. **was looking at older data I think I may have found an error with the way in which alsa initializes this sound device.
The default configuration register for node 0x1d is 90100110
However, if I make no modifications to the pin configs, alsa won't set up the IEC958 mixer controls (non-hdmi) or the CS4208 Digital audio device
ie:
card 0: PCH [HDA Intel PCH], device 1: CS4208 Digital [CS4208 Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
However, if I create the following pin configuration:
static const struct hda_pintbl mb9_pincfgs[] = {
{ 0x1d, 90100110 },
{} /* terminator */
};
alsa sets digital mixer controls and playback device correctly. This is a bit counterintuitive since I'm using the same pin configuration found in /sys/class/sound/hwC0D0/init_pin_configs, but achieve different results.
Takashi --do you why this is happening?
I think I figured out what these lines refer to in the windows driver: #CIR=04h, coeff=0C04h (TX1 ch 0: slot 4, ch 1: slot 12) #CIR=05h, coeff=1000h (TX1 ch 2: slot 0, ch 3: slot 16) these are slots used for each speaker for the TDM configuration 0x0C04 = 0000 1100 0000 0100 **read as two separate bytes 0x1000 = 0001 0000 0000 0000 **read as two separate bytes in macOS, if I change these values to something random ie hda-verb 0x24 SET_COEF_INDEX 0x04 hda-verb 0x24 SET_PROC_COEF 0x0111 It severally degrades the sound quality and introduces heavy distortion. A kernel developer emailed me the other day, here's what he wrote: - Get the schematics for the MB8,1 if you haven't done so already: http://laptopblue.vn/download3.php?id=1794 - One thing I notice in the schematics: GPIO51 on the PCH is AUD_PWR_EN, so this can power the CS codec on/off. Looking at the DSDT this pin is toggled from _PS0 and _PS3 beneath the HDEF device. Theoretically the ACPI core and PCI core should power the device on before a driver is loaded but I'm not sure. Needs to be checked. - There's I2S0 and I2S1 pins on the PCH. The codec is missing in the schematics because it's not on the mainboard, it's on the RIO board and connected with a flex cable but the pinout of the flex connector is given on page 40. For some reason the left and right amplifiers *are* on the mainboard (page 38 and 39), as are the connectors to the speakers (page 40). - On some chipsets audio is only working if the Intel GPU enables certain power wells. I've just looked up the datasheet for the four (!) amplifiers (there's two on each side): https://datasheets.maximintegrated.com/en/ds/MAX98357A-MAX98357B.pdf These chips accept digital audio (I2S or TDM). The DAC is integrated into each chip. I've never seen anything like that before. Pretty sure Apple uses the same digital audio architecture on the 2016+ MBPs. The amps are powered via PP5V_S4, so even in sleep state S4. But they can be put into shutdown via the AUD_SPKRAMP_MODE pin A1. That pin is going to the RIO flex connector, pity we don't have the schematics for that board. started bounty to get this issue resolved. bounty is good for any of the following models: Macbook 8,1, 9,1 and 10,1. https://www.bountysource.com/issues/56233031-macbook8-1-12-inch-early-2015-no-speaker-sound-output/backers David Ulricht prodded me to look into the audio situation on the MBP13,3, here's a braindump in the hope that it might be of use to someone (I don't own such a machine): The MB8,1 uses MAX98357 amps, there's a public spec, it's linked above. The MBP13,3 uses MAX98706 amps, there's no public spec, it may be a custom design for Apple. These amps are more complicated, they have a Reset pin which needs to be driven high for the amps to come out of shutdown and they're connected to the HDA controller with i2c. Maxim introduced another amp this year, the MAX98374, there's a public spec and it looks similar to the amps in the MBP13,3: https://datasheets.maximintegrated.com/en/ds/MAX98374.pdf Specifically, this amp also has a Reset pin, see the timing characteristics on page 24: After driving the pin high, one needs to wait for 1.5 ms before the chip is ready. Presumably driving the pin low when the amps are not used saves power. The pin is attached to GPIO5 on the CS8409 HDA controller. Page 49 specifies the power-up and power-down sequence: After powering up the chip using the Reset pin, the chip needs to be software-enabled via i2c. The i2c pins to drive are GPIO6 (SCL) and GPIO7 (SDA) on the HDA controller. It is unclear to me how the pins are supposed to be used: Is it possible to configure the pins as an i2c bus by sending appropriate commands to the HDA controller? Is this even supported on Linux? Is the i2c bus exposed as a struct i2c_adapter? David Ulricht found i2c hex strings in the Windows 10 registry, presumably these are necessary to initialize the amps: "I2CSpeedMode"=dword:00000001 "I2CPolledMode"=dword:00000001 "I2CQuickMode"=dword:00000001 "I2CBusClear"=dword:00000006 "I2CSlave90Config"=dword:01002090 "InitI2C"=hex:01,90,3a,00,10,10,b0,00,1d,01,00,02,06,00,11,07,01,00,10,09,02,\ 07,03,00,12,01,00,08,13,05,ff,06,00,07,20,02,0d,00,2a,02,02,03,00,04,00,05,\ 02,06,00,07,20,08,02,09,00,0a,80,0b,02,0c,00,0d,a0,01,0c,00,29,02,01,03,02,\ 04,00,05,00,01,01,00,11,01,0a,02,84,00,23,01,00,03,00,02,3f,00,20,01,03,00,\ 1b,75,b6,73,c2,00,11,29,01,21,f3,03,20,05,00,12,00,13,80,00,1c,03,c0 "n0AStreamStartI2C"=hex:01,90,02,00,11,01,02 "n0AStreamStopI2C"=hex:01,90,02,00,11,01,0a "I2CSlave28Config"=dword:00004028 "I2CSlave2AConfig"=dword:0000402a "I2CSlave2CConfig"=dword:0000402c "I2CSlave2EConfig"=dword:0000402e "n02PwrUpI2C"=hex:04,28,2a,2c,2e,07,00,81,01,11,02,32,03,48,04,11,05,10,00,80 "n03PwrUpI2C"=hex:01,28,01,05,00,01,2a,01,05,02,01,2c,01,05,01,01,2e,01,05,03 "ExitI2C"=hex:04,28,2a,2c,2e,01,00,83 "EQ1S1R7"=hex:1e,b2,9a,1a,df,15,c6,f4,11,19,91,ae,c6,f4,11,16,3b,23,16,3b,23,\ d3,89,b9,1f,88,d9,c0,78,b8 "EQ1S2R7"=hex:16,3d,23,16,3d,23,d3,85,bb,1f,8e,8e,c0,73,03,14,62,da,12,94,45,\ d9,23,c2,1d,b9,a4,c2,61,3d "ExitVerbs"=hex:00,05,17,00,01,00,75,04,00,00,74,04,82,00,75,04,00,00,74,04,03,\ 00,75,04,00,80,74,04,04,00,75,04,01,28,74,04,06,00,75,04,00,80,74,04,07,00,\ 75,04,01,28,74,04,65,00,75,04,00,00,74,04,00,03,77,04,03,05,17,00 The MAX98374 spec contains a register map on page 41 and the command format is shown on page 55, but it doesn't really match the hex strings above: The register map starts at 0x2000 and a command contains 1 byte for the device address, 2 bytes for the register address followed by data bytes. And the commands above look like the register address might be 0x903a or 0x3a00 or something. So the command format and register map might not be identical, but maybe we don't have to fully understand the hex strings and it is sufficient to just send them to the amps verbatim. (In reply to Lukas Wunner from comment #72) > The MBP13,3 uses MAX98706 amps, there's no public spec, it may be a custom > design for Apple. These amps are more complicated, they have a Reset pin > which needs to be driven high for the amps to come out of shutdown and > they're connected to the HDA controller with i2c. > > Maxim introduced another amp this year, the MAX98374, there's a public spec > and it looks similar to the amps in the MBP13,3: > https://datasheets.maximintegrated.com/en/ds/MAX98374.pdf Actually, I think this one is the right one to look at (see "Data Sheet" link): https://www.maximintegrated.com/en/products/analog/audio/MAX98372.html The pin configs of that one match those in the schematics for the MBP13,3 exactly, and so do the slave addresses (in the schematics they specify the addresses as the 7 MSB's, i.e. shift-right by one as compared to the data sheet). The registers in this chip have only 1-byte addresses, and range from 0x00 to 0x66 (plus 0xff), but I still can't match this to the Init2C or Exit2C sequences. I think the discussion on the MBP13,* specific parts is best continued on the corresponding bug for those devices, https://bugzilla.kernel.org/show_bug.cgi?id=195671 - I'm posting my results there. David Ulricht has managed to get the speakers working on my macbook 9,1!!! I'll post updates on this in the coming days. I created a github project for the macbook12 audio driver (my first github project) https://github.com/leifliddy/macbook12-audio-driver It's definitely a bit rough around the edges and a bit hacky, but it works. Please test out this driver and give me your feedback. (In reply to Leif Liddy from comment #75) > David Ulricht has managed to get the speakers working on my macbook 9,1!!! > I'll post updates on this in the coming days. I'm terribly sorry to ask the question very late, but can you elaborate the solution conceptually/verbally? (E.g., need to turn on the amp in certain sequence perhaps?) davidjo explains it pretty well here: https://github.com/Dunedan/mbp-2016-linux/issues/108 "the HDA has become pointless - its just transforming the digital PCI audio into a TDM stream for sending to the amps where the real DACs are. All this setup involves totally undocumented coef indexes of the vendor node" so that how this driver works, it's simply replying these undocumented vendor node commands. Thanks for the reply. BTW, your github code is fine, but mic is not working. That's why I'm trying to find a solution. Yes, there's several shortcomings with the current driver. The subwoofer/bass level can't be adjusted, wired HP's don't work, and the internal microphone doesn't work either. It's a bit ironic that the wired HP's and the internal microphone work w/ the stock kernel driver. So, my driver is based heavily off of davidjo's macbookpro driver (which suffers from some of the same issues) https://github.com/davidjo/snd_hda_macbookpro I simply don't have the technical knowledge to implement these features myself. Are you a developer by any chance? I can send you the tools (and instructions) necessary to generate the replay events on a macOS system. But, you would need to sort out how to build the pcm input/capture controls. davidjo could offer you technical advice in that area. Anyways, let me know if you're interested. It seems that the stock kernel has nice structure and hacks so that some Macbook models are working fine. Is it really not a possibility to hack the existing code to make the internal speaker working? I have read the whole thread, and playing around it (and looked at your code too), hopefully, there is a fix with few lines. My gut feeling is that you can hack it - add some setting in the middle of hda_generic if needed. I'd love to find data on the tools to get replay events, i guess it'd be great to get these in some easy-to-find place MacBook (Retina, 12-inch, Early 2015) is marked as vintage by Apple and it will soon become obsolete. Some drivers (sound, bluetooth, webcam and mic) are still missing. Is there a way to merge the drivers or have a package to install them? I own this exact model and I can help with testing Alright, I worked on this for quite a while, but to no avail. I'm probably close at this point, and have gathered up lots of the useful information and put it into a repo in case anyone else wants to take the torch. At this point, I can't really work on it anymore, and besides, this machine has other issues in Linux right now (touchpad/keyboard broken on wake, no BT (Leif's attempt didn't work for the 8,1, overheating issues, etc.) Given the age of this machine, and how much I love it, I think I'm probably just going to let it serve out it's days using OpenCore Patcher until the intel code in MacOS is gone. Here's the link in case anyone wants to review and see where I've gone wrong lol. It was a fun foray into C for a C#/Python dev, anyways. https://github.com/DavidMorton/macbook12-audio-driver wrt comment #83 Current 2021 Mac Pro still have this issue BIOS Information Vendor: Apple Inc. Version: 526.0.0.0.0 Release Date: 11/15/2023 ROM Size: 8 MB Characteristics: PCI is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported ACPI is supported Smart battery is supported Function key-initiated network boot is supported Targeted content distribution is supported UEFI is supported BIOS Revision: 0.1 Handle 0x0007, DMI type 1, 27 bytes System Information Manufacturer: Apple Inc. Product Name: MacBookPro14,1 Version: 1.0 Serial Number: FVFXJ0R6HV2H UUID: 48e9ff4b-4b61-59a0-9961-734f9182f60c Wake-up Type: Power Switch SKU Number: Family: MacBook Pro == This issue has been stalled for 7 months . (In reply to B24Bomber from comment #85) > wrt comment #83 > > Current 2021 Mac Pro still have this issue > > > BIOS Information > Vendor: Apple Inc. > Version: 526.0.0.0.0 > Release Date: 11/15/2023 > ROM Size: 8 MB > Characteristics: > PCI is supported > BIOS is upgradeable > BIOS shadowing is allowed > Boot from CD is supported > Selectable boot is supported > ACPI is supported > Smart battery is supported > Function key-initiated network boot is supported > Targeted content distribution is supported > UEFI is supported > BIOS Revision: 0.1 > > Handle 0x0007, DMI type 1, 27 bytes > System Information > Manufacturer: Apple Inc. > Product Name: MacBookPro14,1 > Version: 1.0 > Serial Number: FVFXJ0R6HV2H > UUID: 48e9ff4b-4b61-59a0-9961-734f9182f60c > Wake-up Type: Power Switch > SKU Number: > Family: MacBook Pro > > > == > > This issue has been stalled for 7 months . This bug report is for the macbook8,1, not the MBP14,1 This driver should support the MBP14,1 https://github.com/davidjo/snd_hda_macbookpro wrt comment #87 Hi I was pointed to this defect through a discussion in https://github.com/davidjo/snd_hda_macbookpro/issues/122 The current Mac-Pro audio does not work in Mint 21 with kernels 5.15 and 6.5.x.25 without adding the butchery from above. These out of tree driver patches are horrible for non-technical users for basic operation of an embedded AUDIO device. I had to pull the 6.5 kernel source to build it. A novice won't be able to do that. This activity needs pushed upstream and added to the current tip of Linux 6.8. Get a proposed working version posted for review on whatever platform you are working on and get it out of these private git repos. Once it is posted to the tip you can back port it to older branches as needed. If you don't have an upstream maintainer from the MAINTAINERS list helping you, it's never going to get resolved. signed retired Linux kernel developer from IBM and Oracle. Please do the right thing. > This activity needs pushed upstream and added to the current tip of Linux 6.8. That's never going to happen. Have you even looked that driver? https://github.com/davidjo/snd_hda_macbookpro/blob/master/patch_cirrus/patch_cirrus_boot84.h It's just replaying macOS cmds. There's no way in hell that's going to make it upstream. > Please do the right thing. Who is that comment directed towards? These drivers were made been open-source developers in their free time. I sort of just hacked my way through over of the course of several month (as I'm not a kernel developer). And I don't have that kind of time anymore to dedicate towards something like this as I've moved on to other projects. If you want a proper driver, perhaps you could raise a bounty or pay a kernel developer to do it. But please don't make demands on people working for free in their spare time. And don't feel so entitled -- you should be thankful there's any driver at all. If you can do it better -- then do it. Contrary to this " free work concept " , the majority of Linux code maintainers are from hardware companies to support their components. In this case Apple and Cirrus. Author: Vitaly Rodionov <vitalyr@opensource.cirrus.com> Author: Vitaly Rodionov <vitalyr@opensource.cirrus.com> Author: Vitaly Rodionov <vitalyr@opensource.cirrus.com> Author: Stefan Binding <sbinding@opensource.cirrus.com> Author: Stefan Binding <sbinding@opensource.cirrus.com> Author: Stefan Binding <sbinding@opensource.cirrus.com> Author: Stefan Binding <sbinding@opensource.cirrus.com> Author: Stefan Binding <sbinding@opensource.cirrus.com> Author: Stefan Binding <sbinding@opensource.cirrus.com> Author: Stefan Binding <sbinding@opensource.cirrus.com> Author: Stefan Binding <sbinding@opensource.cirrus.com> Author: Stefan Binding <sbinding@opensource.cirrus.com> Author: Takashi Iwai <tiwai@suse.de> Author: Christian A. Ehrhardt <lk@c--e.de> Author: Christian A. Ehrhardt <lk@c--e.de> Author: Stefan Binding <sbinding@opensource.cirrus.com> Author: Stefan Binding <sbinding@opensource.cirrus.com> Author: Stefan Binding <sbinding@opensource.cirrus.com> Author: Stefan Binding <sbinding@opensource.cirrus.com> Author: Stefan Binding <sbinding@opensource.cirrus.com> Author: Stefan Binding <sbinding@opensource.cirrus.com> Author: Stefan Binding <sbinding@opensource.cirrus.com> Author: Stefan Binding <sbinding@opensource.cirrus.com> Author: Stefan Binding <sbinding@opensource.cirrus.com> Author: Stefan Binding <sbinding@opensource.cirrus.com> Author: Lucas Tanure <tanureal@opensource.cirrus.com> Author: Stefan Binding <sbinding@opensource.cirrus.com> Author: Stefan Binding <sbinding@opensource.cirrus.com> Author: Lucas Tanure <tanureal@opensource.cirrus.com> Author: Lucas Tanure <tanureal@opensource.cirrus.com> I don't have to look at the driver other than seeing it already exists in the kernel : "sound/pci/hda/patch_cs8409.c" What this does is produce a out of box driver from the original : sound/pci/hda/patch_cs8409-tables.c sound/pci/hda/patch_cs8409.c sound/pci/hda/patch_cs8409.h The proper way to get fixes and additional in the Linux kernel is to add changes at the tip with maintainers and work backwards, not start in the middle. This is why you have a butchered result by patching an existing set of files. It will forever be a maintenance nightmare. This cancer ruins through open source. Abandoned , orphan code. Have a blessed career. |
Created attachment 199111 [details] alsa-info.sh output There is no sound output using the internal speakers on the MacBook8,1. Both the internal microphone as well the combined microphone/headphone jack seem to work properly. I've tried passing model={mba6,mba42,auto}to snd-hda-intel, but still no sound. The startup chime does come through the speakers when the laptop is powered on. There are other issues with the Macbook8,1 --the trackpad, keyboard, and bluetooth are not detected. I don't believe those issues would be related to this one though.