VoiceMeeter Banana & Hangout using Chrome

[mjgraves]

Hello,

Every week I use VMB to co-produce a podcast/Hangout (http://vuc.me) We're a bit involved in how we do it. We have participants all around Europe & North America.

The foundation of the show is a Hangout-On-Air. I interconnect the HOA to a telephone conference bridge that's globally accessible. We have local access numbers in 40 countries. Most people who participate via telephone do so by direct SIP connection. People who participate via telephone are fully interactive with the group in the HOA.

I use VoiceMeeter Banana to provide the audio interconnect between the HOA, a SIP soft phone (Bria 4) and my DECT headset. I also use it to play a prerecorded show opening.

This arrangement generally works great, with one exception. Chrome on my desktop routinely chokes on the audio from VMB. When it does the audience reports that I sound robotic. They say that I sound "Cylon-like."

I've tried a dozen different tweaks over the past year, but I cannot get this problem to go away.

At first I thought there might be a problem with my Sennheiser USB/DECT headset, but I found that playback of a WAV files in VMB is similarly robotic when in the fault state. So it seems that ALL sounds from VMB to the Hangout is impacted.

The definitive solution is to close Chrome completely. Restart it and rejoin the Hangout. And hope that it doesn't happen again.

Is there anything that you can suggest I try? Perhaps a way to gather some more detailed info? Any known issues with interacting with Chrome's audio engine?

Here's a screen shot of my VMB settings.



Routing is a follows:

Input #1 = Sennheiser DW Pro 2 USB headset
- to physical output #2 (a VB-Cable which feeds Bria input to conference bridge)
- to virtual output #1 (audio feed to hangout)

Input #2 = Not used

Input #3 = VB Cable B (sound from Bria soft phone)
- to physical output #1 (Sennheiser DW Pro 2 USB headset)
- to virtual output #1 (audio feed to hangout)

Virtual Input #1 = PC/sound from Hangout
- to physical output #1 (Sennheiser DW Pro 2 USB headset)
- to physical output #2 (a VB-Cable which feeds Bria input to conference bridge)

I have found that my headset works best using MME mode. Since everything we do is wideband telephony (HDVoice), the difference in latency & quality is not an issue.

Today when the problem occurred I tried swapping all use of Virtual Output #1 to Virtual Output #2. Then in the Hangout app I selected the "AUX" output as the source. That overcame the issue without resorting to restarting Chrome.

I wish I could determine exactly what goes awry.

[mjgraves]

Here's a further observation. There's another, older thread here that noted that stability of the outbound stream as being impacted by the stability of the A1 output device.

When my Sennheiser DW Pro2 us set as A1 output the only manner of access that works at all is the MME mode. WDM mode makes odd noises, like the sound is being time stretched. KS mode simply isn't offered.

I set A1 output to be something else, like a VB Cable that's otherwise unused. Then set A2 output to be the headset. Now WDM mode works reliably. Further, when the headset mic is selected using WMD at input #1 the input shows that the headset is operating at 16KHz sampling, which is accurate. That's the best that it can do.

[Vincent Burel]

hello,

yes, basically we recommend to use best audio device as output A1 (it usually means a PCI or onboard card)... but USB headset could do it too... even if some USB device can stop working sometimes after hours...

The preferred audio interface for output A1 is ASIO or WDM. MME is a solution in case of WDM is not working... REM : using MME input device could create deadlock (voicemeeter blocking) , this bug has been corrected in latest version 2.0.3.1

Anyway, to go back to your specific problem, the cause could be more in the Voicemeeter VAIO or VB-CABLE internal parameters... internal latency could be increased to prevent such problem on virtual connection between Chrome and Voicemeeter virtua l I/O or VB-CABLE...

If you have some problem on Virtual connection, you can check the related VB-CABLE configuration, set to 44100 Hz / 7168 smp

VoicemeeterVAIOConfig.gif (27.01 KiB) Viewed 17982 times

[mjgraves]

Vincent,

The virtual inputs show 44100Hz/7168 and 96000Hz/7168 respectively.

This week I did some further experimentation.

A1 - Since the A1 output device seems to be extra important, I set it to be the SPDIF output of the PCs audio interface.
A2 - The Sennheiser USB headset was demoted to A2
A3 - VB cable #2 input - feed to SIP soft phone

I noted that when the Sennheiser headset was in the A2 position I COULD access it via the WDM driver. When in the A1 position only MME works.

During a pre-show period the fault happened again. I was able to ask my co-producer to make a local recording at his end. This is what they hear when the fault occurs.

https://www.mgraves.org/wp-content/uplo ... -28-45.mp3

What does this sound like to you?

As in the past, closing and relaunching Chrome eliminated the problem for a time.

Following that we did a little further investigation. In the Control Panel for the AUX I/O I found that the in/out sample rates were 44.1 KHz, but it was internally operating at 96 KHz.

One of my friends who is experienced with WebRTC development suggests that Chrome might expect 48 KHz. He noted that Firefox is more flexible with respect to audio sample rates.

I changes the control panel to set the AUX I/O to 48 KHz. At that point Chrome last all access to audio. Closing and re-launching it again I was able to rejoin the Hangout with audio.

The fault did not occur again, even though the broadcast ran for another 75 minutes.

Have there been any other reports of problems with VMB interacting with Chrome when 44.1 KHz sampling is used for the AUX I/O?

[mjgraves]

One additional note - for years I've used a screen capture utility called CapSnapper. It's from Cerius Software. http://www.cerious.com/capsnapper.shtml

I could not screen capture the Control Panel for the AUX I/O. When it had the focus the screen capture was not possible. Not for the window or the screen as a whole.

Why would that be? I've not experienced this before for any other application.

[Vincent Burel]

I noted that when the Sennheiser headset was in the A2 position I COULD access it via the WDM driver. When in the A1 position only MME works.

strange, will let me know if the problem is still there after updating to version 2.0.3.1 maybe...

During a pre-show period the fault happened again. I was able to ask my co-producer to make a local recording at his end. This is what they hear when the fault occurs.
https://www.mgraves.org/wp-content/uplo ... -28-45.mp3

yes, I guess this is due to sound discontinuity (chrome does not get all audio signal ot with big cut...)

I changes the control panel to set the AUX I/O to 48 KHz. At that point Chrome last all access to audio. Closing and re-launching it again I was able to rejoin the Hangout with audio.
The fault did not occur again, even though the broadcast ran for another 75 minutes.

ok, Well, so the problem is more in the internal buffer size than internal samplerate (because our VAIO include SRC), the fact is that you get the biggest internal size with this settings: 44100 Hz/ 7168 smp. If you want to understand everything in this domain you can read this note: http://vb-audio.pagesperso-orange.fr/Ca ... ttings.pdf

...But to explain quickly, our Virtual Audio cable or I/O are configured per default to work with a buffering around or below 1024 samples . If an application uses 2048 sample buffer at 44100 Hz (which can be the case with some video game using DX or web application programmed by biologist) it could not work for some of our default settings like 44100 Hz / 4096 smp, or 96 kHz / 7168 smp...

so if setting the VAIO to 44100 Hz / 7168 solved the problem , it means that chromes was using too much big buffer for the current VAIO settings.

Have there been any other reports of problems with VMB interacting with Chrome when 44.1 KHz sampling is used for the AUX I/O?

yes sometimes we got such report, especially when users are decreasing internal buffer of the VAIO or VB-CABLE to try to improve latency, but they often get no sound anymore at the end... reseting to 44100 / 7168 or 4096 solve the problem. But we have some rare case where even 44100 / 7168 settings is not enough, already got the problem with Micosost Lync some time ago...

I could not screen capture the Control Panel for the AUX I/O. When it had the focus the screen capture was not possible

maybe an audio device conflict... the AUX I/O are used by another application ? Otherwise you could also ask to Cerius Software if you can reproduce the problem easily...