In the last couple of weeks, I am occasionally getting dropout warnings in Audacity, but when I zoom in to examine the dropout, it doesn’t exist.
My temp file is on a different partition of my local SSD.
Any ideas why this might be happening?
Thanks
Mac M1 RAM 16GB running macOS 15.7.3, Audacity 3.7.5
The dropout might be too small to be seen in the waveform and noticed by your ears.
You are partitioning an SSD used in a Mac? APFS disks should not be partitioned.
Nope. Zoom in completely. Nothing missing.
I’ve had my SSD split into volumes for 5 years. Not partitioned. My semantic mistake.
This problem has only just recently started.
Did you ever see an Atom? Even under a microscope, you won’t see them - although most (if not all) scientists are sure they exist.
It could be a false positive..
But you can’t tell by looking or listening if there is one missing sample.
And it’s usually not your hard drive/SSD… It’s usually “something else” interrupting your CPU. Your operating system is ALWAYS multitasking and interrupting, even if you are only running one application, and if something (application, driver, process) “hogs” the system for a few milliseconds too-long you get buffer overflow and a glitch, (Buffer underflow on playback.)
If I can’t see or hear the dropout, it doesn’t matter to me and I don’t need the warnings.
I’m curious why this has started recently when I’ve been using this setup for about 5 years.
I’ve turned it off for the moment.
I hope this thread helps others with this.
Ododododo
The operating system has probably had security updates, and it is now doing more in the background than it was before, stealing more slices of time from the audio processing than it used to.
possible I guess …
This is a fairly common “false positive dropout” situation in Audacity, especially on macOS with CoreAudio where the warning system can be a bit more sensitive than what actually ends up audible.
A few likely causes and things to try:
First, Audacity’s dropout warnings are often triggered by buffer underruns or timing hiccups, not necessarily audible glitches. On Apple Silicon Macs, short CPU spikes (Spotlight indexing, iCloud sync, browser activity, plugin scanning, etc.) can briefly interrupt real-time audio even if the recording/playback looks fine afterward—so you get the warning, but no visible “hole” in the waveform.
Try increasing your buffer size in:
Audacity → Settings/Preferences → Audio Settings
Raise buffer length (e.g., 100 ms → 200–300 ms)
If you’re using low-latency settings, switch to a more stable “normal” latency mode
Second, check whether real-time effects or plugins are involved. Even a light plugin chain can trigger warnings if something briefly stalls:
Disable all real-time effects and test again
Try a clean project with no plugins loaded
Third, even though your temp directory is on a separate SSD partition, this usually isn’t the issue—but it’s still worth noting that:
Audacity writes small but frequent temp chunks
If that partition is slightly slower, encrypted, or being indexed, it can still introduce micro-stalls
Fourth, on macOS 15.x specifically, CoreAudio timing can occasionally behave oddly with newer builds:
Make sure you’re using the default CoreAudio host
Try switching sample rate (e.g., 44.1 kHz ↔ 48 kHz) and see if warnings stop
Also worth checking:
Disable “software playthrough” if enabled
Close heavy background apps (Chrome tabs are a frequent culprit)
Turn off Spotlight indexing temporarily to test
Try increasing project sample buffer in Audacity performance settings
If everything seems stable but warnings persist, it may simply be a known Audacity timing bug in 3.7.x on macOS, where the detection threshold is overly sensitive.
If you want, tell me whether you’re recording from a mic/interface or just editing imported audio—there are slightly different fixes depending on that.
Really? What brings you to that conclusion?
This topic was automatically closed after 30 days. New replies are no longer allowed.