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!

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.