OBS with Virtual Audio Cables & Zoom Garbled Sound

aldridgepk

New Member
Hello, I am new to OPS . Running 28.1.2 on windows 11.

I am running audio through a monitor filter to acommodate a 1200 ms delay for my PTZ camera feed.

Pushing output of the filter through VIrtual Audio Cable (VAC). The delay works perfect (audio and video now in synch). Virtual camera feed in Zoom with no problems.

When the VAC is selected in Zoom the audio is garbled, If I use the same direct mic unput into zoom, the audio is clear.

Suggestions?
 

AaronD

Active Member
How is it garbled? Different problems have different sounds: clipping, low bitrate, format mismatch, etc.
 

aldridgepk

New Member
I am not sure the right words. I have attached a zipped MP3 of the trimmed section of the recording. At ~16s point I switch the input to zoom from the Virtual Cable to the mic input. You can hear a huge difference before and after.
 

Attachments

  • audio1806489484 trimmed.zip
    158.8 KB · Views: 60

AaronD

Active Member
I am not sure the right words. I have attached a zipped MP3 of the trimmed section of the recording. At ~16s point I switch the input to zoom from the Virtual Cable to the mic input. You can hear a huge difference before and after.

My first thought on that is a noise reducer that isn't set right. Does the VAC have one?



My second thought is a mismatched sample rate, without resampling. Like the destination expects 48kHz but the source is 44.1kHz, and it just blindly plays out each small buffer as it becomes available. If you were playing a recording, that would appear as ~8% fast, with a corresponding pitch shift. But for live audio, it speeds up each buffer individually and puts silence in between.

If that's the case, then I'm surprised that the "glue" cable doesn't resample. Resampling done right is completely transparent. Maybe you need a better VAC?

Of course, the correct way to fix it regardless, is to match the sample rates all the way through the system. More accurately, match the clocks, as different gear with the same setting can still drift out of sync with each other, but if you're doing it all on the same machine, you're probably okay there.
(USB devices may or may not count as different machines, depending on how each of them works - the USB spec provides a way to synchronize the clock, but it's more complicated than just shoving a bunch of samples into a buffer and sending it up the wire, which is also a USB-acceptable way to do it)

Zooming in on the waveform, there does appear to be a "bump" every 5ms or so, which would be kind of a small buffer, even for internal transport, but entirely possible. But since I'm looking at a lossy-compressed file that only saves the human-perceptible frequency content and makes no effort to preserve the original waveform, I can't tell if it originally had a few samples of silence every 5ms or not.
1671819095424.png

It *would* produce a human-perceptible frequency, to have short-periodic silence like that, and so the MP3 compression algorithm would have kept that frequency while throwing away something else, and then the reconstruction on my end creates an entirely new waveform just from the frequency information that *is* still there.

If you'd send a never-compressed or lossless-compressed version (WAV or FLAC, probably, before Zoom sees it), then it'd be easier to verify the periodic-silence hypothesis.

Audacity is free, and it records as well as editing, analyzing, and playing back. (the above screenshot)

Edit: Just noticed something else: In the bottom-left corner of the screenshot, it has a sample rate of 32kHz. Why? That *is* a standard rate, but anything below 44.1kHz carries a connotation of reducing data at the expense of quality, as the required anti-aliasing filter (lowpass/highcut) is now in the audible range and so it throws away some of the detail. If your audience is old enough to not hear that high anyway, that's fine, but it still raises my eyebrow at least.
 
Last edited:

roleli

Member
1. uninstall the Virtual Cables, restart the machine
2, reinstall the Virtual Cable and restart the machine
3. Share screenshots of your audio setup in OBS
4. Ensure you also have the latest audio monitor plugin ( there was an issue with a recent version)
5. Confirm the Audio setting is 48 kHz is consistent in OBS and in the Virtual Cable (check via Control Panel)
 

aldridgepk

New Member
First: THANK YOU for the work you have done to help. I am scientist, but have little experience with sound engineering. Sorry if I am asking stupid questions.

I am using the virtual audio cable (VAC?) from:

It sets the default rate at 48.0kHz.
Is there a different one I should try?

The Audio inputs are coming via a from a soundboard into the PC using one of these:

The original file from zoom is an .m4a which I loaded into audacity to trim the 1 hr recording down to 15 s for the upload.

Sorry to be thick, are there some things I should try?

The sound going directly from the USB device into Zoom is clear, but passing through OBS/VAC is not: I think I understand your analysis that the VAC is sampling at a different rate the the USB device, so we are getting some aliasing (do I have this right?). From your note: Zoom is recording at 32kHz (?), so should I change the sampling rate for the VAC to 32kHz?
 

aldridgepk

New Member
After more digging in the control panel: looks like the default input sampling rate for VAC is 48kHz but the default output sampling rate is 44.1kHz.

The default rate for the USB input device is 48kHz.

So next step is to make all three match at 48kHz.

Back to church. Stay tuned.
 

AaronD

Active Member
I am using the virtual audio cable (VAC?) from:

It sets the default rate at 48.0kHz.
Is there a different one I should try?
On a Windoze rig (I much prefer Ardour on Linux, but whatever), I have their "cadillac" version - VoiceMeeter Potato - and it does just fine. In addition to 5 channels of its own that can connect directly to physical inputs and 5 more for physical outputs, it also has 3 loopbacks like what you have. Route anything to anywhere, control volume, and a (very) basic set of effects that aren't very useful to me.

Anyway, I would think that the loopbacks in there are exactly the same as yours, so that part is *probably* okay.

The Audio inputs are coming via a from a soundboard into the PC using one of these:
It's incredibly easy to abuse those things without realizing it. The input is designed for a mono mic, that needs a lot of amplification. When you plug a stereo line-level input into it, what would normally be the left channel is taken to be a WAY too hot mic, and so it clips easily, and the right channel connects to a weak power supply that is supposed to go *out* to power the mic. Much less confusing to use an obviously-stereo thing that directly says that it's a line input, like a Behringer UCA202, for example. Search Amazon for it, or wherever you like to buy stuff.

But since you're somehow capable of producing a clean recording anyway, that's not the immediate problem either.

The original file from zoom is an .m4a which I loaded into audacity to trim the 1 hr recording down to 15 s for the upload.
That is probably lossy-compressed in a different way than MP3. Probably AAC. So it throws away the original waveform already, during the original AAC encoding, which needs to be reconstructed in Audacity with less than the original information, and then the export to MP3 throws some of *that* away too. It still *sounds* like the original, but that's all it has left. If you export from Audacity as WAV, then it'll keep everything that Audacity had at least, but there's still the initial lossy encoding before it even got to Audacity.

But since the direct recording from Zoom sounds okay, that's probably not the problem either. It only makes it difficult to see what the problem really was.

I think I understand your analysis that the VAC is sampling at a different rate the the USB device, so we are getting some aliasing (do I have this right?).
*Somewhere* in the chain - don't know where - something is getting a different sample rate than it expects, and instead of actually resampling, it just inserts silence where each buffer falls short. That *somewhere* could be anywhere.

Aliasing refers to the consequence of not sufficiently filtering out everything above the Nyquist frequency, which is half of the sample rate. At 48kHz, for example, Nyquist is 24kHz. Anything above Nyquist gets "mirrored" back down and mixes with the stuff that really is down there. In fact, the entire spectrum from Nyquist up to infinity gets "accordion folded" into the range between 0 and Nyquist. (something that is *at* the sample rate becomes 0Hz or a DC offset, and it counts back up again from there, etc.) THAT is aliasing, and the way to avoid it is to lowpass the signal below Nyquist before sampling it.

In a conceptually simple converter, you would have an analog filter (resistors, capacitors, opamps), followed by a 48kHz converter chip. But a high-order "brickwall" analog filter (so as to keep 20kHz unchanged while completely stopping 24kHz) is both stupidly expensive and way too sensitive to the microweather around it. So the way it's actually done instead, is to sample in the low-to-mid MHz range, which allows a "jellybean" analog filter to do just fine, and then digitally "brickwall" it inside the converter chip before taking only the samples that it actually needs to produce 48kHz at the output. (can you tell I'm an audio engineer?)

From your note: Zoom is recording at 32kHz (?), so should I change the sampling rate for the VAC to 32kHz?
*Something* produced the 32kHz recording that you ended up sending. (Nyquist = 16kHz, which is below the top of "perfect" human hearing at 20kHz) It could be that Zoom did that, or (less likely) it could be that you had Audacity set to do that. I can only see the final product from here.

As for changing everything to 32kHz, that *might* solve it. It's entirely possible that your input card can sample at that rate, and that's what happens when you connect it directly to Zoom. But I would see instead if I could get Zoom up to 44.1 or 48 and match everything to that. Keep Nyquist entirely above audible.

After more digging in the control panel: looks like the default input sampling rate for VAC is 48kHz but the default output sampling rate is 44.1kHz.

The default rate for the USB input device is 48kHz.

So next step is to make all three match at 48kHz.

Back to church. Stay tuned.
Yep. 48k is the preferred "professional" rate. 44.1 comes from CD's, and I think that's mostly because it allowed about 8% more audio on the same size disc. But the margin between its Nyquist and the top end of audible is pretty small.

Multiples of both also exist, and audiophools are all over them, but there's really no audible benefit. In fact, looking at the converters again, most of them actually change modes depending on which multiple you're using (1x, 2x, etc.), so that the initial low-to-mid MHz rate stays the same. So the analog lowpass must also stay the same. The different mode for a higher output rate uses a different internal digital "brickwall" because it can afford to pass more high-frequency content, but it does that by reducing the rolloff rate while keeping the same cutoff right at the top end of audible. So you're not really getting much more "detail" anyway, even if you *could* somehow hear that high. Some yes, but not much.

For one of my projects, I *am* looking at 96k instead of 48k, not because it sounds any different, but because the less aggressive "brickwall" has fewer samples of latency in addition to having less time per sample. This is for a live application where the mic and the speaker are close together, so it'll form a comb filter if I'm not careful, when it mixes acoustically with the original sound. So the higher rate for me in that project is all about timing and nothing whatsoever to do with quality.

But if Zoom is involved, then the distance is probably also enough, considering the speed of sound, that the latency involved with 48k is still negligible.
 
Top