Bluetooth audio delay after idle silence causes missed notification sounds (PipeWire + WirePlumber + AMD Bluetooth)

[rodfarah]

Hello, I'm experiencing a persistent and reproducible Bluetooth audio issue affecting every Bluetooth headset I test on Linux Mint. The problem leads to delayed audio after a few seconds of silence, which causes short notification sounds (including work-related alerts) to be completely missed, since the audio stream “wakes up” too late. I'm opening this issue here because Blueman and BlueZ are part of the Bluetooth stack involved in managing the transport, and I'm trying to understand whether the root cause is related to the Bluetooth layer, PipeWire/WirePlumber policies, or the interaction between them.

Problem summary After ~5–10 seconds of silence, the Bluetooth audio output becomes idle. When a new sound plays (system notification, chat alert, browser audio, etc.), audio starts only 1–2 seconds later, cutting off the beginning of the sound. Short sounds play too quickly for the Bluetooth transport to wake up, so they are completely inaudible. This makes me miss important work notifications throughout the day.

The issue: does not depend on codec does not depend on the application happens with any Bluetooth headset I’ve tested suggests that the Bluetooth audio transport is being suspended during silence

System information Distro: Linux Mint 22.1 Cinnamon Kernel: 6.x (Ubuntu Noble base) Audio stack: PipeWire 1.0.5 + WirePlumber 0.4.17 Bluetooth stack: BlueZ 5 Hardware: AMD-based laptop, internal Bluetooth adapter Headphones tested: Bowers & Wilkins PX7 S2e and also Sony WH-1000XM3 (both exhibit identical behavior). Auto-standby features are disabled on both headsets.

Symptoms and logs When silence occurs, the sink goes from RUNNING → IDLE → SUSPENDED. After that, the next playback triggers a delayed reactivation of the transport. WirePlumber logs show recurring transport errors at the moment the audio resumes: (bluez_output.XX_XX_XX_XX_XX_XX.1-XX) running -> error (Received error event) Failure in Bluetooth audio transport /org/bluez/hci0/dev_... org.bluez.Error.NotAuthorized

This aligns with the behavior of the Bluetooth transport being suspended and later reacquired.

Attempts and troubleshooting already performed ✔ Re-pairing the devices No change. ✔ Testing multiple codecs Tested SBC, SBC-XQ, aptX, aptX-HD, mSBC. Delay occurs in all of them. ✔ Restarting PipeWire/WirePlumber multiple times No effect. ✔ Inspecting PipeWire/wireplumber state The sink always returns to IDLE → SUSPENDED, even after custom configuration. ✔ BIOS update No change. ✔ Attempting to disable WirePlumber’s suspend timeout Created: ~/.config/wireplumber/main.lua.d/51-no-suspend.lua

With:

rule = {
  matches = {
    {
      { "node.name", "matches", "bluez_output.*" },
    },
  },
  apply_properties = {
    ["session.suspend-timeout-seconds"] = 0,
  },
}

table.insert(bluez_monitor.rules, rule)

WirePlumber loads normally, but the Bluetooth sink still enters SUSPENDED. The transport continues to idle regardless of the rule. ✔ Using continuous background audio as a workaround Keeping Spotify playing at minimum volume does prevent the issue, because the transport never enters idle. This confirms the behavior is strictly related to the idle → suspended transition.

Current hypothesis The problem is likely caused by:

PipeWire/WirePlumber suspending the Bluetooth A2DP transport after silence, and

BlueZ taking too long to reauthorize or reopen the transport afterward, leading to the noticeable delay.

However, despite attempts to disable suspension, the transport still goes into SUSPENDED. Given the recurring org.bluez.Error.NotAuthorized messages, there may be a role played by:

BlueZ transport policy Permission/authorization timing Interaction between WirePlumber’s policy and BlueZ A missed configuration option in either component

What I’m trying to understand

Should BlueZ be suspending an A2DP transport this aggressively? Is there any known issue involving AMD Bluetooth adapters + BlueZ + PipeWire? Is Blueman (or BlueZ itself) involved in the idle/suspension behavior?

Are there recommended ways to fully disable transport suspension for Bluetooth sinks?

Any guidance or insight would be greatly appreciated. Thank you!