When playing audio through Bluetooth earbuds, turning on the Mobile Hotspot, toggling Wi-Fi, or opening the SmartThings app immediately causes the sound to disconnect from the earbuds.
The track continues to visibly play in Symfonium in complete silence—the app does not pause or indicate a connection loss. Other music apps (like Spotify/SoundCloud) on this same device do not drop playback.
Device type
Phone
Media provider
Navidrome
Steps to reproduce
1.Connect Bluetooth earbuds and start playing any track in Symfonium.
Turn on Mobile Hotspot (or toggle Wi-Fi / open SmartThings).
Audio immediately drops from the earbuds while the progress bar keeps advancing in silence.
The likely issue is that Samsung Android 16 leaves Symfonium’s active audio track logically playing but no longer audibly attached to the Bluetooth output.
Could you first test setting the Bluetooth output profile’s Fixed PCM output format to 48 kHz / 16-bit, restart playback, and reproduce the Wi-Fi/hotspot/SmartThings action? Please also confirm whether pause/resume restores sound. This will help distinguish a floating-point audio-output problem from a general route-switching problem.
The current log does not contain the actual device used by the active audio track, so a diagnostic build with additional routing information will be needed to make the final fix reliable.
Setting the Bluetooth output profile to 48 kHz / 16-bit did not prevent the drop. However, when pressing Pause and then Play does restore the sound, but only after waiting a few seconds on pause. If I unpause immediately, the sound does not return.
Pretty sure they meant the part about setting output to 48 kHz / 16-bit.
So one log with output set to 48 kHz / 16-bit, and optionally an extra log with the “Fixed PCM output format” set to “Disabled”, like it was by default.
Yep in the logs you actually did not force the output settings to 48/16, can you please try with it enabled ?
Could you please capture two private full Android bugreports: one immediately while playback is still silent after the short pause/resume, and another after pausing for 6–8 seconds and resuming successfully? Please keep the same track, Bluetooth device, and volume throughout. If possible, a third report while another app remains audible through the same trigger would also help.
One note: the uploaded log shows that the actual output was still PCM float, so the forced 16-bit output was not active during this capture.