Make sure that you let TeamSpeak recreate the audio_settings entry first, before setting anything else.
I usually start the client after saving the database, open the audio settings page and close the client again. After that you should™ be able to setup your audio, at least this works for me.
I have .msi installer. Upload on gDrive
https://files.teamspeak-services.com/pre_releases/client/6.0.0-beta3.2/teamspeak-client.msi
HERE IS WHAT WORKED FOR ME.
That worked for me <3
Steps:
After that teamspeak now correctly saves the audio settings for my virtual Microphone (Voicemeeter Out B1)
Whenever I launch TeamSpeak, the microphone is immediately detected as constantly active, even when there is no speech.
The only way I have found to make Automatic VAD behave correctly is to perform the following steps every time I start TeamSpeak:
After doing this, Automatic VAD behaves normally for the rest of the session.
I cannot permanently select any VAD mode other than Automatic. If I select either Volume Gate or Hybrid , the setting appears to change, but as soon as I leave the Audio configuration page (or return to it later), it is reset back to Automatic.
Because of this, the only usable mode is Automatic. Here is a video demo:
I didn’t find a workaround for this issue.
I previously used Volume Gate without any issues because I use SteelSeries Sonar for capture/playback processing and device management. I do not know what changed, but this behavior started occurring recently.
No worries, this issue only exists for almost 5 years, so I am sure the fix is right around the corner.
:)
Do you know if there is any temporary workaround? E.g: re-installing the client.
There are a lot of suggestions in the thread I linked, mostly regarding patching the settings.db. This is neither recommended nor endorsed. Reports of this working or not vary, but you might be lucky.
So far its working, thanks!
I have cleaned the whole database file.
We have also been asking Gamer for almost five years to provide step-by-step instructions for reproducing this issue but he never provided a how-to, so we sadly have not been able to reproduce the problem on our end. :D Just kidding.
Does anyone have a how-to by now for getting into this state?
I mean if we know how to get into this state, we are absolutely willing to fix it.
Using VoiceMeeter Banana on Windows 11, where my default windows devices are set to the Voicemeeter Input and VoiceMeeter Out B1, gives me the unexpected resetting.
I think the Wave Link driver behavior is a very important part of reproducing and understanding this issue.
Elgato has previously warned users when a Wave Link update included a new audio driver that could cause virtual devices to appear differently to applications. For example, the newest Wave Link 3 release note state:
“
This update includes a new Wave Link audio driver update. Virtual devices may appear differently in apps like OBS Studio and Discord - we recommend checking your audio settings in any app that uses Wave Link once the update is complete.”
Importantly, Elgato only posts this warning when a WL3 driver change is actually included. If the driver remains unchanged, they do not issue this warning.
Historically, Wave Link 2 was much more aggressive about replacing audio drivers and recreating WASAPI endpoints. In my experience, Wave Link 2 updates would frequently result in new endpoints being created. Wave Link 3 behaves differently and generally preserves existing devices unless a driver update is specifically required.
Because of that, it is completely expected that applications may occasionally need their audio devices reselected after a Wave Link driver change. That by itself is not the bug.
The bug is what happens afterwards in TeamSpeak.
In my case, when Wave Link recreates or replaces its virtual devices (for example through a driver update, uninstall/reinstall cycle, or any situation that results in new WASAPI endpoints), TeamSpeak can enter a broken state where:
A rough reproduction procedure is:
At this point VAD behavior and settings persistence frequently become broken.
My uneducated guess is that TeamSpeak stores device-specific audio configuration inside the audio_settings blob, including WASAPI endpoint identifiers. When Wave Link recreates its virtual devices and those identifiers change, TeamSpeak does not fully invalidate or rebuild the stored audio configuration. As a result, selecting the new device does not completely recover the audio state, causing both the VAD malfunction and the inability to properly save audio settings.
The strongest indication that this is related to the stored audio configuration is that deleting the audio_settings blob from settings.db immediately resolves both symptoms and forces TeamSpeak to rebuild its audio configuration from scratch.
VoiceMeeter/Elgato Wave Link and some external DAC (e.g. Focusrite Clarett+ 2Pre) cause this kind of problem for over 5 years!
Resetting the magic settings.db or reinstalling of TS6 didn’t helped in my setups.
All my devices and mixers working like a charm in the good old TS3!
After uninstalling and reinstalling Voicemeeter (for an update), I encountered this bug in TeamSpeak 6.
I tried deleting and reinstalling TeamSpeak 6, but that didn’t fix the issue.
I then tried reproducing the bug in a VM and got the same result. Here are the steps to reproduce the bug:
Here are the steps that (I believe) fixed the problem:
I had to re-install everything when my Drive failed. Had the same issue. Looked at this thread and saw a post literally 30 min ago showing a fix.
Tried it and it worked. Absolutely huge and oddly niche. Thanks a ton