You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
A2DP Sink: Device shows "Connected" but no audio is received until manual reconnect #1
This is a known, widely reported A2DP Sink issue across Windows Bluetooth audio stacks.
When connecting a source device (e.g. phone, TV) to AudioPlaybackConnector2, the Bluetooth link pairs and the UI shows Connected, yet no sound is actually received on the Windows PC. In nearly all cases, disconnecting the device and connecting it again immediately restores audio playback.
The problem appears to be rooted in how Windows negotiates or initializes the A2DP audio stream after the initial Bluetooth RFComm/link-layer connection is established. The same behavior has been observed in the original AudioPlaybackConnector, Microsoft’s own Bluetooth Audio Receiver, and other third-party A2DP Sink implementations on Windows 10/11.
Steps to Reproduce
Pair a Bluetooth audio source (phone, tablet, etc.) with Windows via system Bluetooth settings.
Left-click the AudioPlaybackConnector2 tray icon and select the paired device to connect it as an A2DP Sink.
Observe that the tray icon shows the Connected state and the tooltip displays the device name.
Start audio playback on the source device (music, video, etc.).
Listen on the Windows PC – no audio is audible even though the source shows it is streaming to the Bluetooth device.
Left-click the tray icon again, click Disconnect, wait a moment, then click the device again to reconnect.
Audio now plays correctly.
Expected Behavior
Once the tray icon indicates Connected, the A2DP audio stream should be active and Windows should receive audio immediately without requiring a manual disconnect/reconnect cycle.
Actual Behavior
The connection state is reported as successful in the app.
Windows Sound settings may or may not show a new capture/recording endpoint for the Bluetooth source.
No audio bytes appear to reach the AudioPlaybackConnection / AudioGraph pipeline.
Disconnecting and reconnecting (sometimes once, rarely twice) resolves the issue temporarily.
The issue is intermittent – it does not happen on every initial connection, but frequently enough to be reproducible within a few tries.
A recent occurrence also happened after a playback pause while the source was locked. The source playback position advanced, the PC remained selected, and the app reported connected. Windows output/session mute and volume were normal, but sampled audio levels were effectively silent. Pause/resume did not help; a targeted reconnect restored both measured levels and audible playback. A subsequent day of use had no recurrence.
This confirms the symptom and recovery, but does not establish whether the source, Windows/driver, or app lifecycle is responsible. The earlier description's attribution to Windows should be treated as a hypothesis.
If you encounter it, please include app/Windows/Bluetooth-driver versions, source device/player, pause or power-state changes, whether playback time advances, and app diagnostics captured before reconnecting. Use the circular-arrow Reconnect action after collecting the details. Review diagnostics before sharing; crash dumps are not required.
Activity
N0ahTM commentedon Sep 7, 2026
0.9.0 release update: this issue remains open, and the release notes explicitly document the reconnect workaround: https://github.com/N0ahTM/AudioPlaybackConnector2/releases/tag/v0.9.0
A recent occurrence also happened after a playback pause while the source was locked. The source playback position advanced, the PC remained selected, and the app reported connected. Windows output/session mute and volume were normal, but sampled audio levels were effectively silent. Pause/resume did not help; a targeted reconnect restored both measured levels and audible playback. A subsequent day of use had no recurrence.
This confirms the symptom and recovery, but does not establish whether the source, Windows/driver, or app lifecycle is responsible. The earlier description's attribution to Windows should be treated as a hypothesis.
If you encounter it, please include app/Windows/Bluetooth-driver versions, source device/player, pause or power-state changes, whether playback time advances, and app diagnostics captured before reconnecting. Use the circular-arrow Reconnect action after collecting the details. Review diagnostics before sharing; crash dumps are not required.
Aa-creat commentedon Oct 6, 2026
This seems like it can be solved by muting and then unmuteing on Windows. No need to reconnect.