Fix Focusrite Audio (Distortion, Robot sounds & Problems)

Watch the video:

Focusrite is great

However, like a lot in the music industry: it’s focused on Mac.

The Windows drivers leave a lot on the table.

The hardware still works, and great… but it’s not always on all computers.

This guide does fix periodic weird distortion and robot sounds that come from your inputs/outputs every hour or so. Once they occur they persist until the device is removed and plugged in again, or your computer is completely restarted.

We can, however, restart the Windows audio drivers - flushing the audio buffer among other things, fixing the issue. I’m quite positive it’s some kind of ‘buffer overflow’, however, I can’t be certain.

Regardless, either run all the following commands or place them in a .bat file which you can run whenever you need it.

You will need to run CMD as Admin, or open the .bat as admin!

Restart audio drivers

1 2 3 4

net stop audiosrv net stop AudioEndpointBuilder net start audiosrv net start AudioEndpointBuilder

It’s as simple as that.

What causes the audio glitch?

The crackly, robotic-sounding audio that periodically comes out of a Focusrite interface on Windows is almost always a buffer underrun or overrun somewhere in the audio pipeline. The OS, the Focusrite ASIO driver, and your DAW or browser all maintain small audio buffers that hold samples ready to be played or recorded. If those buffers fall out of sync - one side asks for samples that aren’t ready, the other side delivers them late - you hear it as a stutter, a click, a glitch, or, in the worst cases, robotic-sounding output that persists until something resets.

A few common triggers:

• Long uptimes. The longer the system has been running, the more likely small buffer drift has accumulated.
• USB power management. Windows deciding to put the Focusrite into a low-power state, then waking it up, can leave the driver in a confused state.
• Wi-Fi or other high-CPU tasks causing audio thread priority to drop.
• Driver/firmware mismatch. Older Focusrite Control versions paired with newer Windows builds occasionally trigger this.

The reason the bug persists once it starts is that the existing buffer state is broken and the driver never re-syncs it. Restarting the Windows audio service (audiosrv) and the endpoint builder (AudioEndpointBuilder) tears down the audio stack and rebuilds it from scratch, which clears the bad buffer state.

Why Focusrite on Windows specifically?

Focusrite’s first-class platform has historically been macOS. The hardware is the same on both platforms, but the driver team is smaller for Windows, and the Windows audio stack (WASAPI, the USB audio class driver, the various audio services) is significantly more complex than macOS’s Core Audio. The result is that glitches that would be fixed by a macOS driver in milliseconds persist on Windows until the user takes action.

A clean, fully updated install of Focusrite Control plus the latest Scarlett or Clarett firmware dramatically reduces the frequency of these glitches, but doesn’t eliminate them on every system.

Other workarounds

If restarting the audio service works for you, great. If it doesn’t, or if you want to avoid the issue altogether, try these:

• Increase the buffer size in Focusrite Control. Open Focusrite Control → Device Settings → set the buffer size to 512 samples or higher. Higher buffers mean slightly higher latency, but the audio path becomes more tolerant of CPU hiccups. Recommended for mixing, not for live monitoring.
• Match the sample rate in your DAW to the Focusrite’s hardware sample rate. A 48 kHz project running on a 44.1 kHz interface can produce drift over time, and that drift shows up as glitches.
• Disable Windows USB selective suspend for the Focusrite. Device Manager → Universal Serial Bus controllers → USB Root Hub (or the Focusrite’s USB hub) → Power Management → uncheck “Allow the computer to turn off this device to save power.” This stops Windows from sleeping the interface.
• Set Focusrite Control to run as a startup app. Right-click it in the Start menu → More → Open file location → right-click the shortcut → Properties → Shortcut tab → Advanced → tick “Run as administrator.” Then drop the shortcut into shell:startup. This re-establishes the driver handshake every boot.
• Use ASIO instead of WASAPI in your DAW. If your DAW supports it, switch the audio backend from WASAPI to ASIO. ASIO bypasses some of the Windows audio mixing layer and is generally more stable on Windows.

Make the fix permanent

If you find yourself running the .bat file weekly, automate it. Two common ways:

Task Scheduler (recommended):

1. Open Task Scheduler.
2. Click Create Task, not “Create Basic Task” - you want the full options.
3. On the General tab, tick “Run with highest privileges” and pick “Run whether user is logged on or not.”
4. On the Triggers tab, click New and set the trigger to At startup (or on a schedule - every 6 hours is reasonable for problem machines).
5. On the Actions tab, point it at your soundfix.bat.
6. Save. Reboot and check the Task Scheduler history to confirm it ran.

Startup script:

1. Drop a shortcut to soundfix.bat in the Startup folder (shell:startup in the Run dialog).
2. Edit the shortcut’s properties and tick “Run as administrator.”
3. Reboot. The audio services get restarted every time you log in.

The Task Scheduler approach is better because it runs even when no user is logged in, which catches the issue before you do.