Voicemeeter and Statics, Stuttering, Crackling sound & Choppy audio
Posted: Sun Jun 04, 2017 6:54 am
In some cases, Voicemeeter can generate static (cut in the sound) or a robot voice (sound is distorded because discontinued).
This can happend in the first minute... or after having worked well during hours.
In most of cases, you may RESTART AUDIO ENGINE (in Voicemeeter Menu) to get correct sound again.
but if the problem appears too much frequently, it can be a problem of configuration and audio device selection / configuration.
Output A1 device is crucial
Keep default settings (default buffer size / default engine mode) and select your best audio device as output A1 (giving the main stream): ASIO device if present (with 256 or 512 sample buffer size) … WDM or KS (512 sample buffer size) … MME as last choice (512-1024 sample buffer size).
Avoid Audio device Conflict
A typical problem comes when using ASIO Driver as output A1 and selecting the same device with another audio interface (WDM, MME, KS) as hardware input or other BUS. This is an Audio Device Conflict. If you select an ASIO device as main audio device (output A1) you must use ASIO routing capabilities (ASIO PATCH in Voicemeeter system settings) to assign ASIO channels to Voicemeeter physical input or output BUS (generally speaking: DO NOT SELECT THE SAME AUDIO DEVICE TWICE IN DIFFERENT AUDIO POINTS).
Check your Main Stream is stable
The best way to check that your output A1 device is running stable is to use the Voicemeeter banana or Potato integrated Recorder/player to playback some audio tracks and check that there is no problem, no cut, no crack... just the sound you expect.
Device selected as Output A1 gives the main stream
The output A1 device is used to generate the master audio stream, all other I/O and streams will be based on it. So this device must work correct. For WDM device, Voicemeeter opens it in EXCLUSIVE mode per default... But the device could refuse in some cases, or because already in use, or because Eclusive mode is disabled. Then this device will be used in SHARE mode (a "S" is diaplayed in System Settings Dialog box - right to the output A1 Device audio format). In this case, the stream might be unstable and it could be better to use KS or MME.
Audio Gaming:
Some game audio work well only if connected to the default playback device. So we recomment to keep your game playing in default playback device and set a Voicemeeter input as default playback device.
Discord and some other...
some applications like Discord seem to work better with 48kHz audio format, so we recommend to set all devices used by Discord in this format by the Windows Sound Disalog Box -> Properties -> Advance thumbnail.
General rules:
All audio Apps should be connected to Voicemeeter or should not use same audio output device than Voicemeeter (to avoid audio device conflict). That’s why we also recommend to set Voicemeeter virtual audio I/O as default playback / recording device.
In all cases you must test it on significant duration to validate your configuration before going on air.
If the problem remains, send a screenshot of Voicemeeter and its system settings dialog box to let us see your configuration.
If the problem is located in a virtual audio path:
For example from Voicemeeter virtual output (BUS B1, B2 or B3) to a capture application (Discord, Skype, etc...). You may check the internal latency of the related VAIO (virtual audio I/O). The default number is 7168 samples, but in some cases it could be not enough to guarantee a stable stream on virtual link (pending on the buffer used by application connected on - for example 7168 sample could no be enough if the capture app use 4096 samples buffer). Then you may increase internal latency by the VBCABLE_ControlPanel app installed with Voicemeeter (there is one ControlPanel for each virtual audio cable - used as virtual audio I/O by Voicemeeter).
Note the internal latency is applied to the related virtual audio cable used as virtual audio I/O by voicemeeter. So the BUS B1 ouptut is using the same internal latency then the first virtual input. The BUS B2 is using the same than the second virtual input etc...
This can happend in the first minute... or after having worked well during hours.
In most of cases, you may RESTART AUDIO ENGINE (in Voicemeeter Menu) to get correct sound again.
but if the problem appears too much frequently, it can be a problem of configuration and audio device selection / configuration.
Output A1 device is crucial
Keep default settings (default buffer size / default engine mode) and select your best audio device as output A1 (giving the main stream): ASIO device if present (with 256 or 512 sample buffer size) … WDM or KS (512 sample buffer size) … MME as last choice (512-1024 sample buffer size).
Avoid Audio device Conflict
A typical problem comes when using ASIO Driver as output A1 and selecting the same device with another audio interface (WDM, MME, KS) as hardware input or other BUS. This is an Audio Device Conflict. If you select an ASIO device as main audio device (output A1) you must use ASIO routing capabilities (ASIO PATCH in Voicemeeter system settings) to assign ASIO channels to Voicemeeter physical input or output BUS (generally speaking: DO NOT SELECT THE SAME AUDIO DEVICE TWICE IN DIFFERENT AUDIO POINTS).
Check your Main Stream is stable
The best way to check that your output A1 device is running stable is to use the Voicemeeter banana or Potato integrated Recorder/player to playback some audio tracks and check that there is no problem, no cut, no crack... just the sound you expect.
Device selected as Output A1 gives the main stream
The output A1 device is used to generate the master audio stream, all other I/O and streams will be based on it. So this device must work correct. For WDM device, Voicemeeter opens it in EXCLUSIVE mode per default... But the device could refuse in some cases, or because already in use, or because Eclusive mode is disabled. Then this device will be used in SHARE mode (a "S" is diaplayed in System Settings Dialog box - right to the output A1 Device audio format). In this case, the stream might be unstable and it could be better to use KS or MME.
Audio Gaming:
Some game audio work well only if connected to the default playback device. So we recomment to keep your game playing in default playback device and set a Voicemeeter input as default playback device.
Discord and some other...
some applications like Discord seem to work better with 48kHz audio format, so we recommend to set all devices used by Discord in this format by the Windows Sound Disalog Box -> Properties -> Advance thumbnail.
General rules:
All audio Apps should be connected to Voicemeeter or should not use same audio output device than Voicemeeter (to avoid audio device conflict). That’s why we also recommend to set Voicemeeter virtual audio I/O as default playback / recording device.
In all cases you must test it on significant duration to validate your configuration before going on air.
If the problem remains, send a screenshot of Voicemeeter and its system settings dialog box to let us see your configuration.
If the problem is located in a virtual audio path:
For example from Voicemeeter virtual output (BUS B1, B2 or B3) to a capture application (Discord, Skype, etc...). You may check the internal latency of the related VAIO (virtual audio I/O). The default number is 7168 samples, but in some cases it could be not enough to guarantee a stable stream on virtual link (pending on the buffer used by application connected on - for example 7168 sample could no be enough if the capture app use 4096 samples buffer). Then you may increase internal latency by the VBCABLE_ControlPanel app installed with Voicemeeter (there is one ControlPanel for each virtual audio cable - used as virtual audio I/O by Voicemeeter).
Note the internal latency is applied to the related virtual audio cable used as virtual audio I/O by voicemeeter. So the BUS B1 ouptut is using the same internal latency then the first virtual input. The BUS B2 is using the same than the second virtual input etc...