PLEASE HELP : Recording Error: Audio dropout detected

[livie]

Hello,

I am honestly running out of ideas and I don’t know what else to try at this point. Any help or suggestions would be greatly appreciated.

I have been using Nuendo for almost 2 years and, since today, I suddenly started getting this error:

“Recording Error: Audio dropout detected”

The issue happens every single time I start recording. The recording always stops and shows this error. The only random part is the duration before it happens: sometimes after a few seconds, sometimes after up to around one minute.

My setup:

• Windows 11
• Nuendo 15
• MOTU M2 audio interface
• ASIO buffer: 512 samples

Things I have already tried:

• Restarted the computer several times.
• Powered off the MOTU M2 for several minutes and restarted it.
• Disconnected and reconnected the USB-C cable.
• Checked the USB-C cable connection.
• Updated the MOTU M2 driver.
• Updated Windows.
• Updated Nuendo 15.
• Removed recently installed software.
• Tested several different projects:
  • current project;
  • older projects;
  • new empty projects.
• The problem happens in every project, including empty ones.
• Tested different recording locations:
  • external drive with plenty of free space;
  • internal system drive.
• Checked system resources during the issue:
  • CPU usage stays low (around 8–15%, occasional peaks around 30%);
  • RAM usage around 27–36%;
  • disk usage very low.
• One additional IMPORTANT detail: this issue does not happen when I record with another DAW. I tested recording with Adobe Audition using the same audio interface, and I can record for many minutes without any problem. I am currently at 10 minutes of continuous recording with no error, no dropout, and no disconnection.

The issue appeared suddenly today. Everything was working normally before.

Any help would be greatly appreciated. Thank you in advance to everyone who takes the time to help.

[Russ_Thomas]

Wow. That’s pretty terrible.

Out of pure curiosity, I threw your post at Copilot. Here’s the response (hope it helps)

The short version: that Nuendo error almost never comes from Nuendo itself — it’s almost always a sudden, low‑level interruption in the audio stream. And the fact that it appeared out of nowhere on a previously stable system strongly suggests a driver‑level, USB‑level, or OS‑level timing disruption, not a project or disk issue.

Below is a structured breakdown of the actual root‑cause categories that produce this exact error, plus the specific diagnostics that will reveal which one you’re dealing with.

Core takeaway

The error “Recording Error: Audio dropout detected” is triggered when Nuendo’s ASIO engine receives even a single discontinuity in the incoming audio stream. That discontinuity is almost always caused by:

• USB timing instability

• Driver thread stalls

• Windows power‑management changes

• Background processes hooking the audio stack

• Clock‑sync instability inside the interface

Your symptoms — sudden onset, happens in empty projects, happens regardless of disk, low CPU/RAM — point overwhelmingly to USB or driver timing disruption, not Nuendo.

The five real root‑cause categories

Each item begins with a Guided Link so you can dig deeper if you want.

1. USB‑bus instability

This is the #1 cause when the issue appears suddenly.

Common triggers:

• Windows Update silently reassigning USB controller drivers

• A new device enumerating on the same controller

• A cable that still works but has degraded shielding → intermittent isochronous packet loss

• The interface suddenly sharing a controller with a high‑bandwidth device (webcam, SSD enclosure)

Critical tests:

• Move the MOTU M2 to a different physical USB port, ideally on a different controller

• Avoid front‑panel ports and hubs

• Check Device Manager → View → Devices by Connection → confirm what shares the controller

• Try a different USB‑C cable, even if yours “looks fine”

This solves the issue in ~60% of cases.

2. Driver thread stalls

If the MOTU driver’s real‑time thread is blocked even briefly, Nuendo will throw this exact error.

Triggers:

• A background process hooking into the audio stack (e.g., Nahimic, Sonic Studio, Dolby, SteelSeries, Razer, MSI tools)

• Windows installing a new “audio enhancement” component

• A new virtual audio device (Zoom, Discord, OBS, NVIDIA Broadcast, VoiceMeeter)

Tests:

• In Device Manager → Sound → disable every device except MOTU

• Uninstall or disable:

  • Nahimic Service

  • Sonic Studio / Sonic Radar

  • Dolby Access

  • SteelSeries GG

  • Razer Synapse

  • NVIDIA Broadcast

• Check Task Manager → Startup → disable anything audio‑related

This is the second most common cause.

3. Windows power‑management changes

Windows updates sometimes silently re‑enable power‑saving features that break real‑time audio.

Check:

• Power plan → set to High Performance

• USB selective suspend → disable

• PCIe Link State Power Management → off

• Processor scheduling → “Background services” (this is correct for ASIO)

Also check BIOS:

• Disable CPU C‑states (if available)

• Disable global power‑saving modes

4. MOTU internal clock instability

Rare, but it does happen — especially if the interface is powered via USB and the port is unstable.

Symptoms:

• Dropouts occur at random intervals

• No correlation with CPU load

• Happens even at high buffer sizes

• Restarting the interface temporarily helps

Tests:

• Try a powered USB hub (only for testing)

• Try a different USB port

• Check MOTU’s internal sample rate isn’t being forced by another app

• Reinstall the MOTU driver cleanly (remove, reboot, reinstall)

5. Background processes causing DPC spikes

Even if CPU usage is low, a single driver causing high DPC latency can break the audio stream.

Use LatencyMon:

• Let it run for 2–3 minutes

• Look for:

  • ndis.sys (network)

  • wdf01000.sys (kernel)

  • GPU drivers

  • Wi‑Fi drivers

  • Bluetooth drivers

If you see red bars → that’s your culprit.

The fastest diagnostic path (in order)

These steps isolate the root cause with minimal effort.

1. Move the MOTU to a different USB port (preferably a rear motherboard port).

2. Try a different USB‑C cable.

3. Disable all other audio devices in Device Manager.

4. Disable USB selective suspend + set High Performance power plan.

5. Run LatencyMon for 3 minutes.

6. Check for new virtual audio devices (Zoom, Discord, OBS, NVIDIA Broadcast).

7. Temporarily disable Wi‑Fi + Bluetooth (they often cause DPC spikes).

8. Reinstall the MOTU driver cleanly.

One of these will almost certainly reveal the cause.

A non‑obvious insight

Nuendo’s “Audio dropout detected” is not a generic error — it is thrown only when the ASIO engine receives a broken or missing audio packet from the driver. That means:

• The interface did not deliver audio on time

• The driver did not deliver audio on time

• Windows blocked the driver thread

• The USB controller failed to deliver isochronous packets

It is never caused by:

• CPU load

• RAM load

• Disk load

• Project complexity

• Plugins

• Buffer size (unless extremely low)

Your symptoms match a transport‑layer interruption, not a DAW‑layer issue.

One actionable follow‑up

Which of these do you want to check first?

• USB controller + cable

• Driver conflicts / virtual devices

• Power‑management settings

• DPC latency analysis

Pick one and I’ll walk you through it step‑by‑step.

[livie]

Thanks for your reply !

“Your symptoms — sudden onset, happens in empty projects, happens regardless of disk, low CPU/RAM — point overwhelmingly to USB or driver timing disruption, not Nuendo.”

That’s what I thought at first as well. However, what makes me doubt that conclusion is that I don’t have this issue with any other DAW.

For example, I can record in Adobe Audition using the exact same computer, the same MOTU M2, the same USB-C cable, and the same audio driver for a very long time without any dropouts or errors.

So if it were purely a USB or driver timing issue, wouldn’t I expect the same behavior in Adobe Audition as well?

[livie]

Additional tests performed today:

• Disabled ASIO-Guard completely → no change
• Changed ASIO buffer from 512 to 1024 samples via MOTU Control Panel → no change
• Reset/disabled Nuendo preferences and desasctivate external plugin (restarted with Shift+Ctrl+Alt at splash screen) → no change
• Fully uninstalled Nuendo 15 using Revo Uninstaller (including registry/leftover file cleanup) and performed a clean reinstall via Steinberg Download Assistant → problem still occurs
• Problem still occurs identically on both Nuendo 14 and Nuendo 15 after the Nuendo 15 reinstall

The issue still does not occur in Adobe Audition. I can record for 30 minutes or longer without any interruptions.

I’m starting to pull my hair out. Please help me—this is my livelihood, and I honestly don’t know what else to do.

[Russ_Thomas]

Once again, I passed your post over to Copilot. (You could do this yourself.) Here is the response:

The new tests you listed actually tighten the diagnosis dramatically. What you’ve done rules out almost everything inside Nuendo — which means the problem is now almost certainly:

A system‑level timing stall that only Steinberg’s ASIO engine is sensitive enough to detect.

And your new results — especially the fact that Nuendo 14 and 15 both fail identically after a full wipe — are extremely telling.

Let me walk you through what your results really mean, and then I’ll give you the exact next steps that will pinpoint the cause.

Core takeaway

Everything you tested today eliminates:

• Nuendo preferences

• Nuendo configuration

• Nuendo version

• ASIO‑Guard

• Buffer size

• Plugins

• Disk I/O

• Project corruption

• Installation corruption

What remains is not inside Nuendo.

What remains is one of these three categories:

1. Driver callback stalls

2. USB controller timing instability

3. System‑level DPC latency spikes

And here’s the critical part:

Audition will happily record through all three of these failure modes. Nuendo will not.

Your new tests actually strengthen the USB/driver/DPC hypothesis — not weaken it.

Why your new tests don’t contradict the diagnosis

Each item begins with a Guided Link so you can explore deeper.

1. ASIO‑Guard has zero effect on input timing

ASIO‑Guard only affects playback and plugin processing. It does not protect recording.

So disabling it → no change is expected.

2. Increasing buffer size doesn’t fix late driver callbacks

If the MOTU driver is late delivering a buffer, increasing the buffer size doesn’t help. The callback is still late.

Nuendo sees this → stops recording.

Audition sees this → smooths over it.

3. A clean reinstall of Nuendo cannot fix a driver‑level stall

If the driver or USB controller is stalling, reinstalling Nuendo changes nothing.

The fact that Nuendo 14 and 15 both fail identically is extremely strong evidence that the issue is:

• below Nuendo

• below the ASIO engine

• inside the driver, USB stack, or kernel timing

This is exactly what your symptom pattern shows.

The most important clue you just revealed

You said:

“The issue still does not occur in Adobe Audition. I can record for 30 minutes or longer without any interruptions.”

This is the smoking gun.

Audition uses WASAPI, not true ASIO, unless you explicitly force it.

WASAPI:

• buffers more

• tolerates jitter

• hides packet loss

• does not stop recording on dropouts

• does not expose driver callback timing

Nuendo’s ASIO engine:

• requires sample‑accurate timing

• stops recording on any discontinuity

• exposes driver callback stalls

• exposes USB packet jitter

• exposes DPC latency spikes

So your system is currently in a state where:

• WASAPI is fine

• ASIO is not fine

That is exactly what USB timing instability or DPC latency spikes look like.

The next diagnostic will reveal the culprit

You are now at the point where only one test matters:

Run LatencyMon for 3–5 minutes

This will tell us instantly whether the system is producing:

• late driver callbacks

• DPC spikes

• ISR stalls

• kernel scheduling delays

• USB controller timing faults

If LatencyMon shows red bars from:

• ndis.sys (network)

• wdf01000.sys (kernel)

• Wi‑Fi drivers

• Bluetooth drivers

• GPU drivers

• USB drivers

→ that is exactly the kind of stall that Nuendo treats as fatal and Audition ignores.

If LatencyMon shows green across the board → then we pivot to USB controller isolation.

The two remaining root causes

Your new tests narrow the field to two possibilities:

1. USB controller instability

This includes:

• Windows reassigning the USB controller driver

• A new device sharing the controller

• A cable that still “works” but has degraded shielding

• A port that is now delivering unstable power

• A controller that is now producing jitter

This is the most common cause of sudden ASIO failure.

2. System‑level DPC latency spikes

This includes:

• Wi‑Fi driver spikes

• Bluetooth driver spikes

• GPU driver stalls

• Network stack interruptions

• Kernel scheduling delays

• A background process hooking the audio stack

This is the second most common cause.

What you should do next (in order)

This is the fastest path to a real answer.

1. Run LatencyMon for 3–5 minutes

2. Move the MOTU to a different rear USB port

3. Try a different USB‑C cable

4. Disable Wi‑Fi + Bluetooth temporarily

5. Disable all other audio devices in Device Manager

6. Check Device Manager → Devices by Connection See what shares the USB controller with the MOTU.

One of these will reveal the cause.

Which step do you want to take right now?

• Run LatencyMon

• Check USB controller mapping

• Check for driver conflicts

• Test MOTU ASIO directly

Pick one and I’ll walk you through it step by step.

[livie]

@Russ_Thomas

That is exactly what USB timing instability or DPC latency spikes look like.

…

Audition uses WASAPI, not true ASIO, unless you explicitly force it.

You were right

Update: the issue seems to be resolved for now

Steinberg documents a possible issue with certain ASMedia USB host controllers running with the standard Microsoft USB driver, where audio dropouts can occur in SuperSpeed USB 3.1 Gen 1 mode:

UR-C: Audio dropouts in SuperSpeed (USB 3.1 Gen 1) mode

Since my motherboard uses an ASMedia USB 3.1 controller, I tried installing the ASMedia driver provided by Gigabyte for my motherboard.

Unfortunately, this made things much worse: all devices connected through the ASMedia controller stopped being detected. My MOTU M2 interface and external hard drives were still powered, but Windows could no longer recognize them. No more mouse, no more keyboard …

After several failed attempts, I was finally able to completely uninstall the ASMedia driver. After rebooting, Windows automatically reinstalled the native Microsoft USB driver.

The surprising result: with the Microsoft driver back again, Nuendo 14 and Nuendo 15 are now recording normally. I tested continuous recording for 9 minutes without any “Audio dropout detected” message.

I cannot say for sure what fixed the issue. Possible explanations could be:

• the ASMedia driver installation/uninstallation forced a complete reset of the USB controller configuration;

• a previous Windows/driver state was corrupted and was restored during the reinstallation;

• a Windows update or driver-related change may have affected the previous state.

In any case, the ASMedia driver was not a solution for my system.

A warning for other users: if you are running Windows 11 and decide to install an ASMedia USB controller driver manually, be aware that it may cause serious USB issues on some systems (devices powered but not detected), and removing the driver may not always be straightforward.

For now, everything is working again with the native Microsoft USB driver.

Thanks @Russ_Thomas

[Kevin_Ward]

I have the SAME EXACT situation with a high-end Windows 10 machine. I am chasing htis problem now but think I am onto it (maybe) - I have activated Steinberg audio power scheme in the project setup audio section. having activated the Audio performance meter from the transport bar menu, i can see that my processing load has dropped radically lower from 50% that climbs to 100% within the first 30 minutes and finally locks up the software… all the way down to about 15% which is normal. Running tests now but appears to have licked the problem - will update as we test but looking better now.

[livie]

Hi! If you have the exact same issue as I did, did you happen to see my latest update in this thread?

I eventually managed to solve it by fixing the USB controller driver. To solve it, I had tried installing the ASMedia driver (following Steinberg’s recommendation), but it completely broke my USB controller. After I finally managed to uninstall it, Windows automatically reinstalled the native Microsoft USB driver, and since then the “Audio dropout detected” error has completely disappeared. I have now tested 9 minutes of continuous recording without a single dropout.

So, if your symptoms are really identical to mine, it might be worth reading my last post before spending too much time investigating other causes.

I’ll be interested to know whether your solution also fixes it.

Cheers!

[Kevin_Ward]

I don’t use USB, so that was not the source of my issue. My system is Thunderbolt-based—a dedicated 24-track Universal Audio setup using Apollo x8p interfaces.

I have, however, solved the problem. Enabling the Steinberg Audio Power Scheme and leaving it at the disk preload default 2-second setting completely eliminated the issue.

I’m not sure why this resolves it, but it was the only setting in Nuendo 15.0.30 that appeared to be directly related to the read/write behavior during recording, so I decided to try it. None of the other recommendations—including changes to buffer settings or the troubleshooting steps attempted earlier—had any effect on the symptoms. With the Steinberg Audio Power Scheme enabled, I can now record for hours without a single dropout.

One additional observation: I also disabled ASIO Guard from the same settings menu because doing so reduced the Process meter slightly. My system has more than enough processing power, so I don’t see a need to leave it enabled. That said, I don’t believe ASIO Guard is the root cause of the recording error. I re-enabled it and performed another extended recording test, and the system remained stable with no degradation in processing performance. It may have a minor effect on baseline resource usage, but it does not appear to be a primary factor in the recording error.

[livie]

Thanks for the clarification. It looks like we had the same error message but for different underlying reasons. I’m glad you found a solution as well. Hopefully, this thread will help other users identify which path to investigate depending on whether they’re using USB or Thunderbolt.

Thanks for sharing your solution. Have a great day!

[livie]

Hello,

Unfortunately, I have to report that the solution that seemed to fix the issue yesterday did not work after all.

The 9+ minute recording test was probably just luck. This morning, after restarting the computer, the “Audio Dropout Detected” message came back immediately.

I repeated the same USB driver reset procedure as yesterday, but this time it did not help.

I also tried Cegars’ solution with the Steinberg Audio Power Scheme and 2-second Disk Preload setting, but it did not solve the problem in my case.

The issue is still present in both Nuendo 14 and Nuendo 15.

I will open a new topic to continue troubleshooting and will add the link here.

Thanks again for everyone’s help.

[Kevin_Ward]

Sorry to hear that… here is another thread I was working on the same issue if it helps:

Recording Error: Audio drop out detected

In our case, enabling the Steinberg Audio Power Scheme resolved the issue regardless of whether Windows was configured for the Balanced or High Performance power plan. Based on our observations, there was no measurable difference in performance between the two Windows power settings. We also found that the results were identical whether USB selective suspend was enabled or disabled. In all tested configurations, the Steinberg Audio Power Scheme consistently resolved the issue.

this was the exact message we were receiving:

[livie]

Hello everyone,

I am posting this to share a solution if you suddenly find yourself dealing with unexplainable audio dropouts if you have the game League of Legends installed on your computer.

The start of the story : Out of nowhere, I started getting audio dropouts during every single recording, triggering error messages anywhere from a few seconds to one or two minutes in.

Believing my PC was too old—specifically suspecting aging USB ports and outdated drivers—and having planned to get a laptop anyway, I finally took the plunge and bought a brand-new laptop. At first, everything went very well; I installed only my Nuendo recording setup on it, and it was perfect—I could record for 30 minutes without any issues.

As I started settling into the new laptop, I installed my basic favorite apps as well as League of Legends. The next day, when I went back to work in Nuendo, poof—the audio dropouts were back on this brand-new laptop too.

By process of elimination og what news I had intalled from yesterday where all was fine, I tracked down the culprit: Riot Games’ Vanguard anti-cheat software (required for League of Legends). A recent update to this intrusive program apparently interferes with Nuendo’s real-time audio processing.

• On the new PC: Uninstalling League of Legends and Vangard immediately fixed all dropouts.

• On the old PC: Uninstalling only Vanguard (leaving the game and Riot Client installed) made recording work perfectly again, even on those old USB ports of my trusty old PC.

Conclusion: If you experience frequent audio dropouts during recording and play League of Legends, Vanguard is likely the cause.

Remember my previous post about this issue “Audio Dropout Detected” during recording - #3 by livie and PLEASE HELP : Recording Error: Audio dropout detected - #11 by livie @THambrecht @Kevin_Ward @Russ_Thomas