With the latest 6.0.0-beta5 the OBS tracking of audio is not working anymore atleast for users voices. System messages like “Channel Switched” will be recognized by OBS.
Also can you please make auto updates deactivateable. I wanted to switch to the previous TeamSpeak version but always getting auto updated…
Could you please provide a bit more details about the issue? I was able to start recording in OBS with TeamSpeak as a Window Capture, and in my recording both the sound notifications (channel switched, etc.) and other user voices were audible. Are you using any plugins or a different capture method or a specific OBS audio tracking feature?
I have the exact same problem. But i might be able to give some more information.
I have to start TeamSpeak as Admin otherwise I can’t stream games which need to start as Admin.
So when TS is started as Admin OBS doesn’t record other peoples voices, only “microphone muted” etc.
When I start TS normally it works in OBS.
Before the update I was able to record TS as Admin when I also started OBS as Admin. That does not work anymore.
Regardless of whether I start OBS as Admin or not.
Thanks for all the info! I was able to reproduce it.
The key point was using OBS’s “Application Audio Capture (BETA)” when capturing TeamSpeak. Recording without this feature works fine, but when using AAC, users voices are not recognized/captured, while sound packs are captured correctly, most likely because they are just WAV files playing.
Thanks again for the report, I forwarded it to the team and we’ll create internal tickets to track and fix this issue.
A littlebit more of detail from Claude that seems valid:
I reproduced it outside OBS: a WASAPI process-loopback capture (ActivateAudioInterfaceAsync, VIRTUAL_AUDIO_DEVICE_PROCESS_LOOPBACK, include process tree) of the TeamSpeak main process returns all zeros while the process’s own audio session meter shows the voice. A test tone from a separate program is captured normally, but the same tone played with AudioCategory_Communications set via IAudioClient2::SetClientProperties is not captured by process loopback at all. So it looks like beta5 now opens the voice playback stream with the communications category, which Windows excludes from per-process loopback. A device-level loopback still captures it, which is my workaround for now.