Discord Crackling w/VB Out since moving to Windows 2004
Posted: Sat May 23, 2020 5:11 pm
Hello all.
This post might be a bit lengthy, but I'm trying to cover everything that I've tried and discovered about the issue I've had since I've upgraded to the May 2020 Windows feature update. I've removed as many components from my setup as I can that will still let me get to my desired configuration. I was using VB-Cable, but currently have them uninstalled as to not worry about conflicting.
Setup:
Goal: Mix my microphone input & Line in (Currently hooked to an Alexa Input for music), and occasionally my webcam's microphone to the default windows recording (or at least specifically for discord). This was all working well for months, until I did windows updates (incl. drivers).
Software:
Windows 10 Pro for Workstations 2004, Build 19041.264
VoiceMeeter Potato 3.0.1.3
Discord Canary 60661
Hardware Input devices: 1: Microphone via a Wireless Headset, 2: Realtek Audio Line In, 3: Webcam Microphone, 4: [No Device], 5: [No Device]
Virtual Inputs: VM VAIO: Windows Default Playback, AUX: Discord Output, VAIO 3: Unused
Hardware Output: A1: Headset Earphone A2: [No Device], A3: [No Device], A4: [No Device], A5: [No Device]
Virtual Output: B1: Windows Default Recording, B2: [Unused, was OBS], B3: [Unused]
The Line in, and Void Pro are hooked to output B1. B1 is the 'Default Windows Recording' option, but I can also manually select it in Discord as well.
Here's a crummy diagram for the more visually inclined: https://imgur.com/EKy9a7Q
The Problem:
In Discord, the audio when coming from the VB Virtual Output is crackly, robotic, poppy, or even occasionally "drops" like the input cut to -70dB. The 'dropping' mostly can be worked around by disabling the Discord built-in 'echo cancellation', but that just exposes what I think is the real heart of the issue with the "broken" audio that is coming through.
If I switched to directly using a hardware Input, Discord doesn't seem to have the issue at all. So I continued digging.
I've monitored the input via the "VB-Audio Virtual Cable Control Panel" while using the "Let's Check" button in Discord's audio options. There was 0 push/pull loss while it was active, output levels looked like I'd expect, and everything seemed like it should be working.
Closing discord, I opened up audacity and set it's API to WASAPI, Device to VoiceMeeter Output, and started recording. On playback, everything sounded just wonderful. It seemed pedantic, but I tested it with DirectSound and MME though audacity as well. All worked wonderfully.
At this point, I was convinced it was an API issue in Discord. I enabled logging in discord and tested and have combed through the logs. The WebRTC logs discord produced seem to indicate it was unable to open any devices using the Core Audio APIs, often complaining about channel count and sample rates. I adjusted many sample rates (in VM, on physical devices, etc), but changes seemed not to effect the result positively or negatively. Continuing through the logs, I found a message where Discord's WebRTC failed to initialize IAudioClient (it's interface into the Core Audio APIs), and thus falls back to "wave APIs":
The 'Error Details' there definitely seems to be some junk memory, as the garbage output was different every time I ran.
I've spent a little time digging through the WebRTC source, but I'm not quite sure which APIs it's using when it fails out of the Core Audio APIs [I'm reading source now.], but I'm pretty convinced at this point that is likely my problem.
However, it *shouldn't* be falling out of the Core Audio APIs (the HR it's getting back from that Initialize seems to be an `AUDCLNT_E_DEVICE_IN_USE`, but I don't see why it'd be upset about that as best I can tell the VB Aux Input allows sharing, and WebRTC is opening it with `AUDCLNT_SHAREMODE_SHARED`.
I would love thoughts or suggestions for what to look at going forward, because at this moment, I'm quite stumped!
Cheers
Edit to add: It seems the 'Wave' APIs WebRTC uses when it fails out of Core Audio APIs is MME. Which leaves me further stumped, as Audacity has no problems with recording from VoiceMeeter Output via MME.
This post might be a bit lengthy, but I'm trying to cover everything that I've tried and discovered about the issue I've had since I've upgraded to the May 2020 Windows feature update. I've removed as many components from my setup as I can that will still let me get to my desired configuration. I was using VB-Cable, but currently have them uninstalled as to not worry about conflicting.
Setup:
Goal: Mix my microphone input & Line in (Currently hooked to an Alexa Input for music), and occasionally my webcam's microphone to the default windows recording (or at least specifically for discord). This was all working well for months, until I did windows updates (incl. drivers).
Software:
Windows 10 Pro for Workstations 2004, Build 19041.264
VoiceMeeter Potato 3.0.1.3
Discord Canary 60661
Hardware Input devices: 1: Microphone via a Wireless Headset, 2: Realtek Audio Line In, 3: Webcam Microphone, 4: [No Device], 5: [No Device]
Virtual Inputs: VM VAIO: Windows Default Playback, AUX: Discord Output, VAIO 3: Unused
Hardware Output: A1: Headset Earphone A2: [No Device], A3: [No Device], A4: [No Device], A5: [No Device]
Virtual Output: B1: Windows Default Recording, B2: [Unused, was OBS], B3: [Unused]
The Line in, and Void Pro are hooked to output B1. B1 is the 'Default Windows Recording' option, but I can also manually select it in Discord as well.
Here's a crummy diagram for the more visually inclined: https://imgur.com/EKy9a7Q
The Problem:
In Discord, the audio when coming from the VB Virtual Output is crackly, robotic, poppy, or even occasionally "drops" like the input cut to -70dB. The 'dropping' mostly can be worked around by disabling the Discord built-in 'echo cancellation', but that just exposes what I think is the real heart of the issue with the "broken" audio that is coming through.
If I switched to directly using a hardware Input, Discord doesn't seem to have the issue at all. So I continued digging.
I've monitored the input via the "VB-Audio Virtual Cable Control Panel" while using the "Let's Check" button in Discord's audio options. There was 0 push/pull loss while it was active, output levels looked like I'd expect, and everything seemed like it should be working.
Closing discord, I opened up audacity and set it's API to WASAPI, Device to VoiceMeeter Output, and started recording. On playback, everything sounded just wonderful. It seemed pedantic, but I tested it with DirectSound and MME though audacity as well. All worked wonderfully.
At this point, I was convinced it was an API issue in Discord. I enabled logging in discord and tested and have combed through the logs. The WebRTC logs discord produced seem to indicate it was unable to open any devices using the Core Audio APIs, often complaining about channel count and sample rates. I adjusted many sample rates (in VM, on physical devices, etc), but changes seemed not to effect the result positively or negatively. Continuing through the logs, I found a message where Discord's WebRTC failed to initialize IAudioClient (it's interface into the Core Audio APIs), and thus falls back to "wave APIs":
Code: Select all
[000:932] [2156] (audio_device_core_win.cc:2066): IAudioClient::Initialize() failed:
[000:932] [2156] (audio_device_core_win.cc:4286): Core Audio method failed (hr=-2004287478)
[000:932] [2156] (audio_device_core_win.cc:4289): Error details: ⛘ሐˠྣ
[000:932] [2156] (audio_device_core_win.cc:351): AudioDeviceWindowsCore::CoreAudioIsSupported() Failed to use Core Audio Playout for device id=12
[000:933] [2156] (audio_device_core_win.cc:537): webrtc::AudioDeviceWindowsCore::~AudioDeviceWindowsCore destroyed
[000:933] [2156] (audio_device_core_win.cc:584): AudioDeviceWindowsCore::~AudioDeviceWindowsCore() the Avrt DLL module is now unloaded
[000:933] [2156] (audio_device_impl.cc:205): Windows Core Audio is *not* supported => Wave APIs will be utilized insteadI've spent a little time digging through the WebRTC source, but I'm not quite sure which APIs it's using when it fails out of the Core Audio APIs [I'm reading source now.], but I'm pretty convinced at this point that is likely my problem.
However, it *shouldn't* be falling out of the Core Audio APIs (the HR it's getting back from that Initialize seems to be an `AUDCLNT_E_DEVICE_IN_USE`, but I don't see why it'd be upset about that as best I can tell the VB Aux Input allows sharing, and WebRTC is opening it with `AUDCLNT_SHAREMODE_SHARED`.
I would love thoughts or suggestions for what to look at going forward, because at this moment, I'm quite stumped!
Cheers
Edit to add: It seems the 'Wave' APIs WebRTC uses when it fails out of Core Audio APIs is MME. Which leaves me further stumped, as Audacity has no problems with recording from VoiceMeeter Output via MME.
