VB-Audio's Forums

I dug into the Discord WebRTC logs as well as the source code and have finally found a plausible explanation.

Discord uses their own version of WebRTC for the desktop app - the browser version of Discord doesn't exhibit this problem for that reason (viewtopic.php?t=1129).
It seems their version of WebRTC is based on a pretty old implementation of the official version.
The way that old implementation works is that if even one device is unable to be initialized, CoreAudioIsSupported returns false, Core Audio gets disabled and Discord falls back onto the Wave APIs.

The function was changed in a Dec 06, 2019 commit (https://webrtc.googlesource.com/src/+/e ... 3cf23e738e) as it doesn't make sense to disable Core Audio entirely if only one device fails.
But why would a device fail if everything is correctly configured and working well? Simply, VoiceMeeter needs exclusive access to the A1 device for it to output properly - setting the A1 device in the device properties to not allow applications to take exclusive control results in very distorted audio through VoiceMeeter. Having that device be exclusive to VoiceMeeter doesn't cause problems with many apps because most apps don't add a layer on top of the official WebRTC implementation.
But in Discord's case, they use a pretty old version of the function that checks for Core Audio. That function, in order to check for Core Audio, initializes every recording/playback device one by one. When the function checks for every device and stumbles upon the A1 device that's set to be exclusive, it is unable to initialize it and marks Core Audio as disabled, marking every subsequent device as having failed initialization too...

In short, there is nothing that can be done unless VoiceMeeter releases the A1 device when Discord is first opened or Discord updates their code base, which likely won't happen anytime soon given that the commit is over a year old now and still isn't present in Discord's version.

Nevertheless, I can attest that disabling exclusive mode for the A1 device (and I suppose, any other hardware device in VoiceMeeter) fixes the initialization errors in the Discord logs. I can't test whether or not the crackling of the microphone still happens given that all audio is distorted when A1 isn't in exclusive mode.

interesting.

note Discord does not have to check all audio devices. but only the ones set as default device or set as default communication device.

Voicemeeter uses WDM (WASAPI) audio playback device in exclusive mode, first because needs a direct access to device to reduce latency; secondly because the WDM Share mode often does not work well with output device (while it works correct with input device).

that's why this output device (used by Voicemeeter output A1 for example) cannot be used by another application.
One workwarround is to select the device with MME interface instead of WDM...

but this is not explaining the problem of choppy sound on Discord. Maybe they should consider using more direct API than webRTC to manage audio device and audio stream...

note Discord does not have to check all audio devices. but only the ones set as default device or set as default communication device.

It doesn't have to, but by checking whether Core Audio is supported, it checks every device instead of only the relevant ones. The implementation of the Core Audio check is literally two 'for' loops over every recording/playback device, and if one of them fails, all other ones are marked as having failed.

I still think it's part of the explanation for choppy sound on Discord as the problem doesn't appear in the browser version that uses the browser's webRTC implementation. In the desktop app, it is their own implementation and maybe the choppy sound simply comes from Discord falling back to Wave APIs.

One workwarround is to select the device with MME interface instead of WDM...

I just tried this out and it works. Discord correctly initializes every device and enables Core Audio APIs.

a guy on youtube ("cas curse") told me:

It's not about what it does before opening the stream, it's CONSTANTLY opening streams, that's the problem. Every few seconds or less, it attempts to initialise and open a new device (and according to the above, it does so by attempting to initialise EVERY device, EVERY time). On top of this, when it does open devices, it's doing so in a strange manner where it appears to exist twice in the device graph (perhaps not waiting for the old device to be closed before opening the new one?). This is just like a network stack failing when it is flooded. There is more data to process, than there is time to process it.

thanks to ask to Discord dev team to correct this in Discord application (apparently it works better in browser).

That's me, mate

Hawpe's digging in the logs and analysis of the source code has been a real eye opener for us all, so props to him for really figuring this out. But if you take his observation about the way webrtc handles devices before opening, and then my observation that discord is constantly opening devices in a loop (control panel app volume dialog... Watch discord have two devices simultaneously and destroy and create them over and over)... Suddenly it becomes very obvious why the system is not working. Discord is spamming device initialisation to every audio device in the system over and over, endlessly.

I am uneffected by this issue, so I cannot test it, but the discord forums are full of complaints about crackling mics (as a result of the audio device handling) going back as far as discord existed... I guess Win 2004 and the high demands of voicemeeter are just exposing a long-standing bug to us.

Some discord users have reported that using the 'legacy' audio subsystem in discord bypasses the issue. In fact, I have not read a single report of that option not working. I don't know what it does, but I'm guessing it's an audio implementation which does not use the broken webrtc implementation. If that is the case, it's maybe the best way for us to deal with it all, until discord make a few fixes.