Bluetooth BIGInfo Broadcast Audio Debugging Guide
Broadcast audio failures are easy to blame on the speaker or phone, but the useful clues often arrive earlier: BIGInfo timing, BIS indexes, encryption flags, presentation delay, and whether the receiver ever had enough data to join the stream.
TL;DR: Use Bluetooth Explorer to record BIGInfo fields, broadcast code expectations, BIS index mapping, periodic sync state, presentation delay, and PHY before changing playback logic.
Why does BIGInfo matter?
BIGInfo tells a receiver how to understand a broadcast isochronous group. If the receiver never sees the right timing, encryption, or BIS structure, later audio debugging is mostly theater.
What should Bluetooth Explorer capture?
Capture periodic sync state, BIGInfo presence, BIS count, BIS index, PHY, framing, encryption flag, and presentation delay. Those fields explain whether the receiver can even attempt the stream.
How should teams retest?
Run one open broadcast, one encrypted broadcast, and one wrong-code attempt. Keep the same receiver placement so sync quality is not confused with authorization or metadata problems.
When is it not an audio bug?
Do not blame codec or speaker output when BIGInfo is missing, the BIS index is wrong, or the broadcast code expectation does not match. The stream has to be joinable first.
| Evidence | Likely meaning | Next move |
|---|---|---|
| Periodic sync works, BIGInfo missing | Receiver sees the advertiser but cannot learn the broadcast group | Check broadcaster configuration before audio code |
| BIS index does not match UI choice | The app may be joining the wrong stream | Map BIS indexes to visible program names |
| Encrypted flag differs from expected code | Join failure may be authorization, not radio quality | Retest open and encrypted broadcasts separately |
How do you keep the retest honest?
- Record whether periodic sync happened before checking audio behavior.
- Write down BIS count, BIS index, and presentation delay.
- Separate open broadcast tests from encrypted broadcast tests.
- Keep receiver placement fixed for the first three captures.
- Map each visible program choice to the raw broadcast metadata.
What should users ask?
What is the first BIGInfo debugging clue?
Check whether periodic sync succeeded and whether BIGInfo is visible before blaming audio playback.
Why does the BIS index matter?
The BIS index tells the receiver which stream inside the broadcast group it is joining.
When should teams inspect broadcaster setup?
Inspect setup when BIGInfo is absent, encryption flags are wrong, or BIS mapping does not match the user interface.
Useful references
Bottom line: Bluetooth Explorer turns broadcast audio debugging into concrete BIGInfo, BIS, encryption, and sync evidence before teams chase playback symptoms.