Audio Output Fails After Resume from Suspend

[jeremy-nuss]

When I put my 2016 12" MacBook in suspend and wake it up the audio no longer outputs. The device is visible and the volume controls appear to work, but no sound plays.

When connected to an HDMI display, sound will play through the monitor, but no matter what, it will not play through the internal speakers.

I'm not sure what all logs I need to provide to help troubleshoot the issue. Please let me know what you need, and I will happily provide it.

Operating System: Fedora Linux 43
KDE Plasma Version: 6.5.4
KDE Frameworks Version: 6.21.0
Qt Version: 6.10.1
Kernel Version: 6.17.11-300.fc43.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ m3-6Y30 CPU @ 0.90GHz
Memory: 8 GiB of RAM (7.6 GiB usable)
Graphics Processor: Intel® HD Graphics 515
Manufacturer: Apple Inc.
Product Name: MacBook9,1
System Version: 1.0

[jeremy-nuss]

One potentially relevant piece of information is that I got sleep working on my Mac using the following steps, as found here:
https://bbs.archlinux.org/viewtopic.php?id=296508

I am using s2idle, not deep.

`{10:35}~ ➭ ls /lib/modules/$(uname -r)/extra
modinfo snd-hda-codec-cs420x
lspci -nnk | grep -A4 'Audio device.*8086:9d70'
lsmod | grep -E 'snd_hda_intel|cs420x'

snd-hda-codec-cs420x.ko.xz
filename:       /lib/modules/6.17.11-300.fc43.x86_64/updates/snd-hda-codec-cs420x.ko
description:    Cirrus Logic CS420x HD-audio codec
license:        GPL
rhelversion:    10.99
alias:          hdaudio:v10134208r*a01*
alias:          hdaudio:v10134207r*a01*
alias:          hdaudio:v10134206r*a01*
depends:        snd-hda-codec,snd-hda-codec-generic,snd-hda-core
name:           snd_hda_codec_cs420x
retpoline:      Y
vermagic:       6.17.11-300.fc43.x86_64 SMP preempt mod_unload 
00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-LP HD Audio [8086:9d70] (rev 21)
        Subsystem: Intel Corporation Device [8086:7270]
        Kernel driver in use: snd_hda_intel
        Kernel modules: snd_soc_avs, snd_sof_pci_intel_skl, snd_hda_intel
00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-LP SMBus [8086:9d23] (rev 21)
snd_hda_intel          73728  2
snd_intel_dspcfg       45056  5 snd_soc_avs,snd_hda_intel,snd_sof,snd_sof_intel_hda_common,snd_sof_intel_hda_generic
snd_hda_codec_cs420x    90112  1
snd_hda_codec_generic   139264  1 snd_hda_codec_cs420x
snd_hda_codec         233472  9 snd_hda_codec_generic,snd_soc_avs,snd_hda_codec_hdmi,snd_soc_hda_codec,snd_hda_codec_cs420x,snd_hda_intel,snd_soc_hdac_hda,snd_sof_intel_hda,snd_hda_codec_intelhdmi
snd_hda_core          159744  12 snd_hda_codec_generic,snd_soc_avs,snd_hda_codec_hdmi,snd_soc_hda_codec,snd_hda_codec_cs420x,snd_hda_intel,snd_hda_ext_core,snd_hda_codec,snd_sof_intel_hda_common,snd_soc_hdac_hda,snd_sof_intel_hda,snd_hda_codec_intelhdmi
snd_pcm               212992  15 snd_soc_avs,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,soundwire_intel,snd_sof,snd_soc_sdca,snd_sof_intel_hda_common,snd_compress,snd_sof_intel_hda_generic,snd_soc_core,snd_sof_utils,snd_hda_core,snd_sof_pci_intel_skl,snd_pcm_dmaengine
snd                   155648  19 snd_hda_codec_generic,snd_seq,snd_seq_device,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_sof,snd_soc_sdca,snd_timer,snd_compress,snd_soc_core,snd_pcm
`

{10:37}~ ➭ cat /sys/power/mem_sleep s2idle [deep]

[physics1024]

Seem as here. I guess the sleep mode turned down power of the DAC and when resuming the initialization isn't applied.
Maybe we need to inform the BIOS not to turn down the power of the DAC.

[jeremy-nuss]

I'm a Scrum Master not a coder. Forgive me for using Gemini (and the emoji in the shell script) to try and fix this issue. It walked me through several failed attempts, but did eventually land on a solution that works.

In short this is what it found,

"Since you are already in s2idle mode, the issue is almost certainly that the specific PCI bridge for the audio card is still cutting power too aggressively.

My previous attempt to disable this power cut (d3cold) likely failed because I used the standard Intel audio address (00:1f.3), but the 12" MacBook uses a unique internal bridge (usually 01:00.0) for its custom Cirrus logic.

I have updated the fix-macbook-audio.sh script to:

1. Auto-detect the correct PCI address for your specific audio card (instead of guessing).

2. Disable d3cold power gating for that specific device.

3. Create a udev rule to make this setting permanent across reboots (so you don't need to run the script every time)."

Script:

audiofix.sh

#!/bin/bash

# Updated Fix for MacBook 12" (2016) Audio
# Focus: Disabling D3Cold on the CORRECT PCI bridge.

echo "--- MacBook Audio Sleep Fixer ---"

# 1. Auto-detect the Audio PCI Device
# We look for the 'Cirrus' or 'Audio' device, but exclude the main Intel controller if a specific bridge exists.
# On MacBook 9,1/10,1 this is often 01:00.0
AUDIO_DEV=$(lspci -D | grep -iE "Cirrus|1013:4208|1013:8409" | head -n 1 | awk '{print $1}')

if [ -z "$AUDIO_DEV" ]; then
    echo "⚠️  Could not auto-detect Cirrus device. Falling back to standard Audio controller."
    AUDIO_DEV=$(lspci -D | grep -i "Audio" | head -n 1 | awk '{print $1}')
fi

if [ -z "$AUDIO_DEV" ]; then
    echo "❌ Error: No audio device found in lspci. Is the driver loaded?"
    exit 1
fi

echo "✅ Found Audio Device at PCI Address: $AUDIO_DEV"

# 2. Disable d3cold (The Power Cut)
# This prevents the kernel from cutting power to the bridge during s2idle
D3_PATH="/sys/bus/pci/devices/$AUDIO_DEV/d3cold_allowed"

if [ -f "$D3_PATH" ]; then
    echo "   Current d3cold status: $(cat $D3_PATH)"
    echo "   Disabling d3cold..."
    echo 0 | sudo tee "$D3_PATH" > /dev/null
    echo "   New d3cold status: $(cat $D3_PATH)"
else
    echo "⚠️  Warning: d3cold_allowed file not found at $D3_PATH"
fi

# 3. Make it Permanent (udev rule)
echo "--- Installing Permanent Fix (udev) ---"
UDEV_FILE="/etc/udev/rules.d/10-macbook-audio-power.rules"

# We get the Vendor and Device ID for the udev rule
VENDOR=$(cat "/sys/bus/pci/devices/$AUDIO_DEV/vendor" | sed 's/^0x//')
DEVICE=$(cat "/sys/bus/pci/devices/$AUDIO_DEV/device" | sed 's/^0x//')

echo "   Creating udev rule for Device $VENDOR:$DEVICE..."

cat <<EOF | sudo tee "$UDEV_FILE" > /dev/null
# Disable d3cold for MacBook Audio ($AUDIO_DEV) to fix sleep death
ACTION=="add", SUBSYSTEM=="pci", ATTR{vendor}=="0x$VENDOR", ATTR{device}=="0x$DEVICE", ATTR{d3cold_allowed}="0"
EOF

# Reload udev rules
sudo udevadm control --reload-rules
sudo udevadm trigger

echo "✅ Udev rule installed."

# 4. Verify Sleep Mode
echo "--- Verifying Sleep Mode ---"
CURRENT_SLEEP=$(cat /sys/power/mem_sleep)
if [[ "$CURRENT_SLEEP" != *"[s2idle]"* ]]; then
    echo "⚠️  Warning: System is not in s2idle mode. Current: $CURRENT_SLEEP"
    echo "   Attempting to switch to s2idle..."
    echo s2idle | sudo tee /sys/power/mem_sleep > /dev/null

    # Update boot args if grubby exists
    if command -v grubby &> /dev/null; then
        sudo grubby --update-kernel=ALL --args="mem_sleep_default=s2idle"
        echo "   Updated boot arguments for s2idle."
    fi
else
    echo "✅ System is already in s2idle mode."
fi

# 5. Clean up old script attempts
OLD_SCRIPT="/usr/lib/systemd/system-sleep/macbook-audio-fix"
if [ -f "$OLD_SCRIPT" ]; then
    echo "--- Cleaning up old sleep scripts ---"
    sudo rm "$OLD_SCRIPT"
    echo "   Removed old brute-force script ($OLD_SCRIPT)."
fi

echo ""
echo "🎉 DONE. Please REBOOT your MacBook to ensure all rules apply correctly."

[a-chaudhari]

I have a method to fix the audio rather than disabling power saving settings to work around it.

I created a windows vm with the cirrus device passed through to it, the original bootcamp driver, and using a modified qemu binary that'll log all HDA verbs going to the chip. This lets me record all commands being sent from the original driver to the audio codec. I then used a LLM to create a script that'll read the file and replay those same commands.

This worked, and I have now a script that'll fix the audio output until the next suspend/restart.

Someone can also compare these commands to the ones sent by the driver, find the differences, and submit a pr so the driver correctly initializes the codec. I don't know when I'll have time to do this.

Attached is the raw dump file as well as the replay script. You'll need the hda-verb command on your computer, usually provided by the alsa-tools package from your distro for it to work.

sudo python3 ./replay.py captured_verbs.txt

captured_verbs.txt

replay.py

My system details:
Early 2016 Macbook 12 inch
MacBook9,1
Arch Linux 6.16.8
KDE Plasma 6.4.5
This is an old installation from June 2025. I'm also using w/e version of this driver was around then.