Summary
The TS6 client opens both the capture and the render device at startup and keeps
active WASAPI sessions for as long as the process runs — while idle, while not
transmitting, and while not connected to any channel. On Windows with a Bluetooth
headset this has concrete, user-visible consequences that make the client
effectively unusable with that hardware class.
Environment
- Windows 11 Pro 26200
- TeamSpeak 6 client (
TeamSpeak.exe, build 2025-05-27) - Bluetooth Classic headset (Haylou S30), Microsoft
BthA2dpstack - Intel Wireless Bluetooth adapter
Observed behaviour
1. Capture side forces HFP permanently.
Selecting the headset microphone makes Windows switch the headset from A2DP to
HFP. Because the client never releases the capture device, the headset stays in
hands-free mode — mono, 16 kHz — for the whole session. Every other application
on the machine loses stereo output until TeamSpeak is closed.
Measured native formats on this machine:
| Device | Native format |
|---|---|
| Internal mic array | 48000 Hz, 2ch, 16 bit |
| Headset mic (HFP) | 16000 Hz, 1ch, 16 bit |
2. Render side keeps an active session even when silent.
With capture moved to a different microphone, the client still holds an ACTIVE
render session on the headset endpoint. Enumerating sessions on the default
render device via IAudioSessionManager2, with the client idle and silent:
TeamSpeak pid=4520 Active <-- silent, not in a channel
Spotify pid=2624 Inactive <-- paused, released
TextInputHost pid=21412 Active
3. This breaks Bluetooth multipoint.
Most multipoint headsets arbitrate by which source is actively streaming. Because
the client never lets the PC go silent, the headset never yields to the second
connected device. A phone paired via multipoint cannot play audio at all while
TeamSpeak is open. Closing the client restores it immediately and reliably.
The net effect: the only configuration that works is one where neither the
capture nor the render device is the headset — which defeats the point of owning
one.
Comparison
Discord opens the capture device when joining a voice channel and releases it on
leaving; its render session goes idle the same way. Same machine, same headset,
no profile lock and no multipoint breakage. This is a device-lifecycle difference,
not a Bluetooth limitation.
Request
Release — or at least let go idle — the capture and render devices when the client
is not in a voice channel, or when it has been idle for some interval. An opt-in
setting such as “release audio devices when idle” would be enough.
Note that Push-to-Talk does not help here: it gates transmission, but the device
stays open, so the profile lock and the multipoint blocking persist regardless.