M3 Max (BCM4388), macOS 15.6.1: A2DP to an SBC speaker shows 57% ReTx and constant packet drops; a non-Apple sender to the same speaker is clean (FB25169767)

I have a reproducible Bluetooth audio fault on my MacBook Pro M3 Max and have narrowed it down as far as I can from user space. I have filed it as FB25169767. I am posting the data here in case it helps others with the same log lines, and in case an Apple engineer can say what to capture next.

I used AI tools for this investigation: Claude to run the tests and analyse the logs, and ChatGPT for web research. I did the listening tests myself, and the outside sources quoted below were checked against the originals.

My setup

• MacBook Pro M3 Max (Mac15,9), macOS 15.6.1 (24G90)
• Bluetooth controller: Broadcom BCM4388, firmware 22.5.542.2788
• Sink: Creative T100 desktop speaker, Bluetooth 5.0, A2DP, SBC only
• Negotiated: SBC 44.1 kHz joint stereo, bitpool 52, 322 kbps, 5 frames x 117 B per packet every 14.51 ms, L2CAP MTU 672
• The speaker is about 25 cm from the Mac, with line of sight. Wi-Fi is on 5 GHz. A Magic Trackpad is connected.

Symptom

I have heard audible gaps from this speaker in every app for years. My AirPods and Sony WH-1000XM4 on the same Mac do not glitch.

What bluetoothd reports for my speaker

A2DP LinkQualityReport, one line a second while streaming:

A2DP LinkQualityReport: Handle = 11 ReTx = 75.8% (135 / 178), NAK =    0, NoSync =  135, TxPwr =  7 dBm, RSSI =  -46, {50,75,90}th Noise = {-102,-102,-101} for 29 ch, 2EDR pkts = 138, 3EDRTx pkts =   0, HDR4Tx pkts =   0, HDR8Tx pkts =   0, ... CoexDenial =   0, CoexRequest =   0, ... TxFlush pkts =  0, Tx2Flush pkts =   0, rate = 322 kbps Flow off = 0

Over 11,808 reports from my normal use (3.3 h of streaming, 12 to 13 October 2026):

This is what the drops look like in my log:

[Server.A2DP] A2DP packet flushed: L2CAP (chip) flush occured. Current sequence=28, timestamp=40557459
[Stack.L2CAP] Write in progress (status=65535)
[Server.A2DP] A2DP packet flushed: Audio Queue full, remove oldest and insert sequence=29 (latest), timestamp=40557479

Every one of the 2,670 "Audio Queue full" drops in that period comes with an L2CAP "Write in progress (status=65535)" on the same thread in the same millisecond, just before it. The other 795 drops are "L2CAP (chip) flush occured". So most of the lost audio is discarded on the host when the previous write to the controller has not completed yet.

Other details:

• The report's TxFlush pkts, Tx2Flush pkts and slot counters are 0 in every report for this link, also in seconds with a logged chip flush.
• Flow off is above 0 in only 19 of 2,835 seconds (one capture), so the controller's ACL buffers are not usually full.
• bluetoothd logs "Setting flush timeout, chipId:23" and "Dynamic Latency settting flush timeout to 200 ms" at AirPods events, never at this speaker's stream start.
• Audio Timesync for this link: "Audio Delivery Average Time" 9750 to 16750, "Pending Packets" 18 to 27, "Queue depth" up to 8.

Second symptom: CoreAudio overloads

With this speaker, bluetoothd logs Initiate Audio Delivery Speed Change (0.9x or 1.1x) about once a second. With AirPods it happens only at stream start. Each change shifts the HAL clock: safety_violation_time_gap median 7.9 ms, max 20.9 ms (1,645 reports). Any client with a 256-frame IO buffer (Chrome Web Audio uses 256 below 96 kHz) then logs HALS_OverloadMessage: Overload possibly due to safety violation 50 to 100 times a minute.

I ran a silent test: a CoreAudio client playing digital zeros to the speaker, 40 s per buffer size.

A bigger buffer stops the overloads but not the packet drops.

Control experiment: a non-Apple sender to the same speaker

I plugged a USB Bluetooth 4.0 dongle (Broadcom BCM20702A0) into the same Mac. macOS attaches no Bluetooth driver to it, so I could drive it from user space with BTstack (port/libusb, a2dp_source_demo). Same desk, same distance, same SBC bitpool 52 at 14.51 ms intervals.

• 2 min 24 s of audio, and I listened to all of it: 9,892 of 9,892 media packets completed, no flush, no audible gap.
• Packets in flight: median 2, max 5.
• Send to Number Of Completed Packets: median 27 ms, p95 48 ms, under 70 ms in steady state.
• BTstack sets no automatic flush timeout and never discards late packets.

So my speaker's receiver and my room are fine. The fault is in Apple's transmit path for this link: bluetoothd, the BCM4388 firmware, or the link policy between them. This test cannot say which.

What I ruled out

Nothing I changed moved ReTx from 50 to 60%, and it does not follow RSSI between -36 and -56 dBm.

• Bluetooth off/on (ReTx 57.8% before, 58.8% after), re-pairing (64% after)
• Trackpad traffic (0 reports/s, ReTx 56%), Wi-Fi coexistence (5 GHz, CoexDenial 0)
• Lid open, nearby LED lamps unplugged, monitor USB-C cable unplugged, Mac moved 2 m away
• Audio content: digital silence behaves the same as music

I have not yet tried a fresh boot (the Mac had been up 116 days), macOS 15.8.1 or a PacketLogger capture.

Related

• Asahi Linux found that Apple's Broadcom controllers (BCM4377/4378/4388) need vendor command 0xFC57 (ACL priority) for clean A2DP, and that the whole audio connection must stay high priority while it carries audio: one low-priority packet, such as a volume change, causes a dropout (netdev list, 15 April 2026, "[PATCH v2] Bluetooth: Add Broadcom channel priority commands"). An earlier capture showed macOS sending 0xFC57 plus vendor commands 0x1DD, 0x205 and 0x22D per connection at playback start.
• A similar write-up with the same three log lines, ReTx 51.4% at -36 dBm, but triggered by sleep/wake and cured by Bluetooth off/on (which does not help me): https://note.com/honest_kudu5817/n/n7e8a12aecb13

Questions

1. Does macOS apply a different link policy to a non-Apple SBC sink than to AirPods (ACL priority, automatic flush timeout, packet types, Dynamic Latency)? Does "Link Adaptive Packet type support=0" mean this link is excluded from something?
2. Is 0xFC57 held for the whole stream, or dropped around AVRCP traffic such as volume changes?
3. What does NoSync count exactly, and why would it be more than half of all transmissions at -40 dBm?
4. Is there anything I can capture beyond PacketLogger with the Bluetooth logging profile that would help the Bluetooth team?

Has anyone else seen "Write in progress (status=65535)" paired with "Audio Queue full" on a steady link like this, and found anything that changes it? I am happy to run more tests or share more logs.