Blue Yeti Pro latency compensation?

[Misha]

With this specific question it's almost inevitable that some will offer a suggestion of interface.  Just want to be clear upfront. I do have a decent interface and studio mics. This is for a different purpose.

About 15 years ago I experimented with USB mic. Particularly Blue Yeti Pro. (That was way before Logi bought them). This mic had amazing features at the time, especially 24 bit recording and the fact that you can use it as USB or XLR.  I've made whole bunch of recordings with this mic using USB, but switched to standard studio mics about 7 years ago.  A few computers, operating systems and Cakewalk versions... 

I decided to re-visit the mic, as it has a very particular sound.  What I found is that using XLR through interface sounded differently. Probably because of pre-amps. However, when I plugged it in as a USB device, I got the sound I was after. The problem is latency. Clips come at about 1 seconds late.  If I do low buffer of even 256, starts crackling. 

Yes, driver is ancient, but I was wondering if this clip placement can be set somewhere globally to compensate for certain time, so future recording with this mic will respect that, unless I change it back.

Again, kindly no lectures on how bad USB mics are. This is for specific purpose. Please let me know if this is possible.

Thank you!

P.S. I do have a very different (much newer) USB mic, it doesn't have this issue. So  I believe the only solution is to use some kind of manual offset for this particular mic.

[Amberwolf]

 

3 hours ago, Misha said:

The problem is latency. Clips come at about 1 seconds late.  If I do low buffer of even 256, starts crackling. 

That is a pretty long latency.  I wonder what they have the driver doing that it takes that long to process--it seems pretty unusable for a mic presumably intended to be a live audio source.   

EDIT2: This page

https://sharklatan.com/fix-microphone-blue-yeti-usb-advanced-audio-device/

has info on fixing certain issues; I don't know if any of them would fix a latency problem. 

EDIT3: YOu didn't say which driver or driver mode you're using, but if you're using ASIO4all to get this mic working with ASIO, it would probably work better to uninstall that and use the native WDM/KS or WASAPI driver it has instead (since that's what the ASIO4all is actually using anyway, and just adding ASIO4all's own latency on top of that. 

EDIT4:  Also, it may make a difference whetehr you have it plugged directly into the computer's USB port (and which port it's plugged into), vs thru a USB hub or some other device's USB plug that then feeds into the computer (like some computer keyboards have, for mice and other things to be used without using up your computer's ports). 

 

3 hours ago, Misha said:

Yes, driver is ancient, but I was wondering if this clip placement can be set somewhere globally to compensate for certain time, so future recording with this mic will respect that, unless I change it back.

Do you mean something that automatically shifts the clip position after recording is stopped to put them where they should have been?   

 

Other thoughts:

Depending on the version of software (CbB, Sonar) you have, there is a "time+" to adjust the playback time of tracks.  It doesn't affect the recording of new material, so you would basically just be syncing the existing stuff in the project to whatever is coming in on the new one.   With a delay of a whole second, that would be pretty hard to work with. 

There isn't a way to add a negative value to the incoming stuff to match the unaltered playback time of the existing project (it would have to play before the signal was actually coming into the program  ). 

 

 

 

3 hours ago, Misha said:

I decided to re-visit the mic, as it has a very particular sound.  What I found is that using XLR through interface sounded differently. Probably because of pre-amps. However, when I plugged it in as a USB device, I got the sound I was after.

FWIW, if there is no other solution, you could open the mic up and trace out the circuits, then find the output from the preamp (if it's a separate piece from the USB conversion; it might not be), then install a jack for that to run to your regular interface.  Not necessarily an easy task, and there is risk of damage that could leave it inoperative or even unrepairable. 

EDIT5: this page http://recordinghacks.com/microphones/Blue-Microphones/Yeti-Pro says there is already a 1/8-inch stereo headphone jack, which the "fact sheet" says is "Zero-latency headphone output with volume control for direct monitoring".   This has to be post-preamp (and so have the sound quality you're after), so you could use this signal directly into your regular audio recording interface, and thus have only the IF's latency to worry about.  

 

EDIT1: This video (for a different purpose) shows the disassembly of one of the Yetis (dunno if it's the same model) to give you an idea of what is involved in disassembly. 

... https://youtu.be/1yxUSUbJkwk

 

 

Edited Sunday at 05:02 PM by Amberwolf
added more info

[David Baay]

If you have 'Use ASIO Reported Latency' enabled under Preferences > Audio > Sync and Caching, that should largely be compensating for the input latency. There's always some additional unreported hardware/firmware latency that needs to be compensated by entering a value for Manual Offset, bbut this is usualoy on the order of only 30-50 samples - approximately a millisecond. Normally, I would recommend using the Centrance Latency Checker to find the actual RTL, but since your output and input devices are using different drivers, that's not going to work.

First, make sure that your Record and Playback Timing Masters are referencing the correct drivers and note the ASIO Reported Latency in samples (sames as Total Roundtrip reported on the Driver Setting page). Then disable latency compensation temporarily and re-record playback of a clip with a single sharp transient - like a single Metronome click - with the mic right up against a  monitor. Change the Now Time readout to samples and use the Now Cursor positioin to count the number of samples from the source transient to the uncompensated recorded transient; this is the Actual Round Trip Latency. Subtract the Reported RTL from that Actual RTL figure, and that's what you need to enter for Manual Offset in samples. Enter the offset, re-enable compensation, and try re-recording again.

 

 

Edited Sunday at 04:43 PM by David Baay

[Amberwolf]

I added some other stuff I found to my first reply, but this one may be the "easiest" solution so I'll post it separately as well, to make it easier to find:

This page http://recordinghacks.com/microphones/Blue-Microphones/Yeti-Pro says there is already a 1/8-inch stereo headphone jack, which the "fact sheet" says is "Zero-latency headphone output with volume control for direct monitoring".   This has to be post-preamp (and so have the sound quality you're after), so you could use this signal directly into your regular audio recording interface, and thus have only the IF's latency to worry about.  

[Misha]

Thanks for giving this a shot!!

I am using official Blue ASIO driver.  It's old, but seems installs & recognizes everything without the issues. I started with easiest solution and found something strange. 

I went into: Preferences > Audio > Sync and Caching and saw that it was syncing to ASIO4ALL.... I changed that to Yeti clicked OK, re-opened Preferences, it switched back to ASIO4ALL clicked OK (tried Apply too, same result). Could this be the issue?  Is there a reason it silently switches back to ASIO4ALL?

Here is a video clip of what's happening:

https://www.youtube.com/watch?v=Dp1YCTMVdr4

 

-------

P.S. I have an Apogee one usb mic from about 5 years ago, works like a charm.  Zero issues.

 

 

[Amberwolf]

I'd recommend removing all vestiges of ASIO4all from the system entirely.  It's known to cause various issues in CW/CbB/Sonar/etc, because of the way it works.   It doesn't work in "low latency", it's minimum latency is whatever the WDM/KS or other driver your device has, *plus* it's own latency, plus...whatever you have to use to get it to "work" in your program. 

It isn't really an ASIO driver, it's a wrapper for whatever other non-asio audio drivers are on the system, and it does them "all", so if there's a problematic driver somewhere (even if you never use it) it could cause problems for anything using A4A. 

 

It could easily be causing your issue, especially if that Blue ASIO driver worked before installing ASIO4all or on a previous system that didn't have A4A on it. 

 

 

Edited Sunday at 10:21 PM by Amberwolf

[Bristol_Jonesey]

1 hour ago, Amberwolf said:

I'd recommend removing all vestiges of ASIO4all from the system entirely.  It's known to cause various issues in CW/CbB/Sonar/etc, because of the way it works.   It doesn't work in "low latency", it's minimum latency is whatever the WDM/KS or other driver your device has, *plus* it's own latency, plus...whatever you have to use to get it to "work" in your program. 

It isn't really an ASIO driver, it's a wrapper for whatever other non-asio audio drivers are on the system, and it does them "all", so if there's a problematic driver somewhere (even if you never use it) it could cause problems for anything using A4A. 

 

It could easily be causing your issue, especially if that Blue ASIO driver worked before installing ASIO4all or on a previous system that didn't have A4A on it. 

 

 

This is good advice. You will also need to remove any reference to it from the Windows Registry.

If you're unsure what to do, let us know BEFORE you attempt anything.

[Misha]

I think this IS the right approach. I removed ASIO4All. 

What I got now in  Preferences > Audio > Sync and Caching are two choices 

#1 - Generic Low Latency ASIO Driver

#2 - Yeti Pro ASIO 

Same deal with trying to replace #1 for #2-  it switches by itself to #1 again... mystery. I think one of non-Bandlab's  daws installed that Generic ASIO. Cubase? Reaper? I dunno.

However, even with this Generic Low Latency Asio driver, it seems it solved the issue with ridiculous latency.   The question is, should I investigate further, or follow the golden rule of not touching c#ap if it doesn't stink?  My wild guess is something is up with compatibility between (ancient, but special) Yeti driver and Cakewalk and my fear is that if I try to remove that strange Generic driver, mic might not want to work at all. Could it be that Cakewalk is avoiding problematic driver in such way that it just falls back to the next available without reporting error? 

 

In any case, it is for the most part resolved, and I thank you all for giving this time!!! 

[Amberwolf]

"Generic Low Latency Asio driver" may be something installed by some other software (such as realtek sound chip, or came wiht some audio program or standalone synth, etc.   

As long as it is a *real* ASIO driver, it shouldn't cause you problems if you deselect it from the available drivers in CbB/Sonar/CW, so that when you are using the Yeti driver it can't affect anything.  Only one ASIO driver can be used at a time within CbB/etc, so you probably already have to do this in order to use the yeti's actual driver anyway. 

If the generic one is a wrapper like ASIO4all, and not a real ASIO driver for a specific piece of hardware, and just lets you use "any" device on your system as ASIO, then it's not what you want to use either.  

 

If you find it impossible to deselect within CbB/Sonar/etc so that you can use the Yeti driver instead, you can disable it in Device manager in Windows itself (rightclick My Computer and choose Manage) or you may be able to disable it in the Sound control panel (rightlcick on your windows volume control speaker icon, and choose Playback devices.  Rightlcick on the generic one, and choose Disable.  Click the recording tab, and do that again. Ok to dialog, go restart CbB/Sonar and it shouldnt' show up in the audio devices list anymore. )

 

Edited Monday at 03:08 AM by Amberwolf

[Sock Monkey]

Go into the Reg editor and under software look for ASIO. Delete all but your actual audio interfaces. You might have a few legitimate drivers which is fine. But anything that says generic, Realtek. Steinberg generic or Magix.Nuke em. 
They are what are called invasive drivers that can interfere with your proper divers. This is a common Sonar issue. 

[Misha]

Thanks for additional info. I've never seen a realtek installing Asio shell by itself... As I've mentioned, most likely it was installed by another DAW.  Again, as long as it works, I don't want to touch anything, as I have no clue why  Cakewalk keeps on switching to something else instead of Yeti specifically here : Preferences > Audio > Sync and Caching, while everywhere else in Cakewalk it is pointed to correct driver. 

 

 

 

 

 

 

[azslow3]

9 hours ago, Misha said:

Thanks for additional info. I've never seen a realtek installing Asio shell by itself... As I've mentioned, most likely it was installed by another DAW.  Again, as long as it works, I don't want to touch anything, as I have no clue why  Cakewalk keeps on switching to something else instead of Yeti specifically here : Preferences > Audio > Sync and Caching, while everywhere else in Cakewalk it is pointed to correct driver.

This particular setting is just displayed confusing way. It is technically a table with all interfaces, so you can set custom latency for any. You probably see the same list as in Audio/Devices. The dialog starts with "the first interface", even when it is not active.

[Misha]

"this particular setting is just displayed confusing way. "

I don't think it's just displaying, seems like it's referencing to whatever is selected . ASIO4ALL was at that specific place, the only reference in Cakewalk, while the native driver was selected elsewhere (in Cakewalk).  The only way to get rid of it was full uninstall of ASIO4ALL.

This semi-permanent solution works for now.  Hopefully works till summer.

[Sock Monkey]

This has been my experience as well. I have seen literally dozens of posts here over the years with people having audio driver issues and it’s the first thing I always advise. Check that dialogue and if it doesn’t show your interface you then have an invasive drivers and  that is causing the problem. Removing the invasive driver always solves the problem. 
And sometimes you can uninstall it but the ultimate solution is to easily remove it from the Registry. 
 

And it’s not always a third party generic driver. 
I had one case where my old Tascam us1641 ASIO driver showed up there even though it had not been connected in probably 3 years. 
I hand not removed the driver because normally legitimate drivers don’t interfere. 

I had just bought my Zoom L8 and installed the driver and when I was checking that everything was working I noticed the Tascam was showing in the Sync Caching latency dialogue. 
And as always you can’t change it. So I had to delete it in the Reg Editor. 

 

[azslow3]

8 hours ago, Misha said:

"this particular setting is just displayed confusing way. "

I don't think it's just displaying,

 

7 hours ago, Sock Monkey said:

I had just bought my Zoom L8 and installed the driver and when I was checking that everything was working I noticed the Tascam was showing in the Sync Caching latency dialogue. 
And as always you can’t change it. So I had to delete it in the Reg Editor.

People, have you ever tried to CHECK which latency compensation is applied? I mean the one you see when you open the dialog (so just randomly the first interface in the system) or the one for currently active interface? You don't even need precise loop-back test, just set huge different  values so you can notice the effect easily.

 I don't advise keeping disturbing drivers in the system. Some are well known for influencing other drivers (especially ASIO4ALL). But many users have many interfaces and so they are all installed. And MY observation is that dialog in question always shows the same interface, independent from currently active one. And that is not a problem.

May be the behavior  on your system is different, but that conclusion should be from real observation... Only then there is a chance Cakewalk will try to pin and solve the bug. So far (and there was many threads about that particular setting) there was not a single evidence there are problems with it.

[Xoo]

@azslow3 is right - the display is unhelpful, but the latency adjustment for the current driver is applied, not the first one displayed.

[Sock Monkey]

He is no longer with us but I believe it was years ago that @scook posted that that box was important to stability of the driver. So I’ve always have passed that information along. I also think that I’ve seen Staff members advising too. @msmcleod?? 
 

Edited Tuesday at 03:34 PM by Sock Monkey

[Misha]

"He is no longer with us"   Ohh no.  Sad...... He helped me so many times.

[57Gregy]

On 1/28/2025 at 1:33 PM, Misha said:

"He is no longer with us"   Ohh no.  Sad...... He helped me so many times.

No longer part of the forum. 😉

[Misha]

Phew.  I wish people would chose words a bit more carefully.  I don't know the insights, but hope he is OK.

----------------

Again, thank you everyone for chipping in.  Seems like completely removing ASIO4ALL solved the lagging issue and Cakewalk is using native ASIO driver of Yeti.

 

P.S. While Yeti PRO has several downsides, after so many years, I still consider it one of the best  24bit USB Microphones ever made (and it has XLR!) that has dedicated ASIO driver written for it, not a shell.  Recently AKG Lyra - USB mic which has similar, multi-polar features and excellent reviews went on deep sale, unfortunately  it's WASAPI only.  As Meatloaf said:  "But I Won’t Do That".   I do have a decent interface, but  find Yeti very special using it as a  USB mic. I think it has to do with circuitry that was designed specifically for those capsules. In my understanding, using XLR bypasses internal pre-amp.