Sample rates over 48k no longer work

Cubase 15.0.30
Windows 11 Home 25H2
UA Apollo Thunderbolt

I’m not sure when this started because my normal sample rate to use is 48k. However, when I recently loaded an old project recorded at 88.2, the playback is distorted and crackly. Some experimentation shows this to be the case for any project I create at any sample rate over 48k - I open up a VST instrument and the sound crackles like there’s a word clock mismatch.

If I convert the existing 88.2 project audio to 48k, it plays seamlessly, indicating the audio files themselves are not corrupted.

In both UA Console and in Windows I can see that the sample rate switches correctly to follow the project settings. I have tried both low and high buffer settings in UA Console.

I have followed all UA recommendations for optimizing for Windows 11 and for Thunderbolt. My Gigabyte motherboard BIOS is up to date and all BIOS settings are as UA recommends.

In Cubase I have tried ASIO Guard on and off, Steinberg Power Scheme on and off.

I’m out of ideas, so any help would be appreciated. Hopefully, it’s just some “can’t believe I was so stupid” setting I’ve overlooked.

Thanks

Hi,

Increase the Buffer Size of your Audio Device, please.

Yes, I have tried that. Increased it to a medium value, then increased it as far as it could go.

As you may be aware, doubling the sample rate will also increase the amount of processing of ALL the project VSTs while halving the time available to do that processing. If any of the VSTs use oversampling techniques, the situation could get worse.

With periodic reports from users trying to get consistent results at “normal” audio rates, one has to realistically evaluate if you are getting sufficient benefit from the increased sample rates to justify the additional resources required.

Thanks for all that. As I said I generally record at 48k. Regardless of any discussion of what sample rate should have been used or the subjective value of one rate over the other, the actual scenario is a project recorded at 88.2 that previously played back with no issues.

I’ve worked at 96k 24bit for years and never had a problem. I’m using a Presonus Quantum 2626 with TB3 into a TB4 port on my motherboard. Maybe I don’t have problems because I’m not converting projects, just .wav files(mostly sfx).

The issue did not arise from converting the project - but the conversion revealed that the audio was not corrupted.

I’ve had the same experience as you @Cookie_Jarvis - never had any issues at any sample rate before.

Can you change to 88.2 and then open the project to see if it’s smooth?

It’s already at 88.2.

Ah! I thought you had Cubase set to 48k and was trying to open the 88.2 project :slight_smile:

No, this is a case where a project was previously recorded at 88.2, so all the audio in it is 88.2, and everything sounded proper.

If I now play the project, it is distorted and crackles. I have tried switching Cubase to 88.2 in advance of opening the project, and also just opening the project and letting Cubase switch automatically. In either case, I also check to confirm that the Apollo has correctly switched to 88.2 as well.

Nothing has been added to this project at all since it was working - no new tracks, no new plugins, etc…

That has a pretty specific sound with many devices, and will be continuous. So you’re hearing 100% of the audio like that, or does the glitching happen at discrete points?

Was that done way back when those same projects worked on this same PC, or was that done after you first heard the glitching? A lot of tweaks are counterproductive at best and if you’re getting word clock mismatch types of sounds, then it’s not a DPC or any similar issue, and increasing buffer sizes, ASIOguard, etc. are not going to have any effect.

Not all devices correct sync to clock even when they say they have. If this sounds like a sync issue, go into Windows, change the Windows sample rate to 88.2 for all IO on the Apollo, reboot, and then go directly to the 88.2 project. That will help determine what may be happening.

Pete
Microsoft

It’s continuous. I’ve already done what you’re suggesting.

So you

  • Changed the sample rate in Windows for all IO on the device
  • Rebooted
  • Ensured that you immediately opened an 88.2 project and that Cubase or Windows didn’t do a 48k init before you opened that project.

If so, I’d suggest talking with UAD, because the entire signal chain, including clocking through the ASIO interface, is coming from their driver and hardware.

I’ve seen lots of cases in the past where devices and their drivers don’t actually resync despite indicating they did. Nothing from UAD, though.

Pete
Microsoft

Already talked to UA, which is what led me here.

Your project at 882… does it have to stay at 882?

This is going to sound strange… but something happened last year where my motu is no longer happy at 441 or 882. 48 is fine… but it actually works best at 96. At 441 or 882 I get little dropouts, even when just playing a file in vlc. The programs dont seem to even know this is happening.

In theory 96 should put a bigger load on PC but not in my case, at least using Thunderbolt. For USB devices doesn’t seem to matter.

I have just gotten in the habbit of running everything at 96 and doesn’t happen anymore unless something changes sample rate on me unannounced (usually firefox)

Hi,

Try to test your system by using LatencyMon utility.

I guess you’ve already tried just restarting the computer.

In the UAD Console, is your clock set to internal?

Yep, restarted (did all the IT Crowd stuff) and yes, the Apollo clock is internal.

Is that a 24 i/o ? I had the same thing happen with me. Over the years, all 4 of my 24 i/o units eventually died in that way. It’s some chip in there related to sync that goes bad over time. I found it minimized any sort of glitching or other problems only if I ran it at 96. But when they were ready to die completely, they would just lose sync all the time. There’s a trick you can do with flicking the voltage selection switch up and down rapidly with it unplugged. The skeptic in me says that’s just snake oil, but I’ve never cracked one open to see what’s connected to that.

Pete
Microsoft