Random playback dropouts - VER 3.7.8

Feedback and Discussion Forum Audacity 3.x Feedback and Reviews
1

I posted this to GitHub as a bug report as well. A search didn’t find anything current. Sorry if this was posted improperly.

So here goes:

I have encountered an unusual playback problem involving older .aup3 projects that were copied from one computer to another. I have done a fair amount of troubleshooting and believe the project audio itself is intact.

Systems tested

  • ASUS1: older ASUS laptop, Windows 11. This is the computer on which the affected project was originally created and edited.
  • ASUS2: newer ASUS laptop, Windows 11, Ryzen 7 8840HS / 24 GB RAM, fresh Audacity installation.
  • MacBook Pro M5: current macOS and current Audacity version.
  • Windows Audacity version: [confirm exact version in Help > About Audacity]
  • macOS Audacity version: [confirm exact version]
  • Windows audio host normally used: WASAPI
  • No real-time effects are active in the affected project.
  • The main test project is about 6 minutes long, ~1.20 GB, with 11 active tracks plus several muted tracks.

Main symptom

On Windows, several copied versions of one project family (“Wild Horses”) develop random playback dropouts.

The dropouts:

  • occur at different locations on different playbacks;
  • are therefore not repeatable at a particular timestamp;
  • do not produce visible gaps or defects in the waveform;
  • have not appeared in exported mixes;
  • sometimes begin only after playback has been running for roughly a minute;
  • may disappear temporarily after closing/reopening Audacity or after saving/backup operations.

What I tested

  1. The original Wild Horses .aup3 on the ASUS1 internal C: drive plays cleanly.

  2. Copies of several Wild Horses .aup3 files made previously to an external SSD showed random dropouts when played in Windows Audacity.

  3. Copies transferred onto the ASUS2 internal C: drive also showed the same behavior. Therefore this does not appear to be simply an external-USB-drive playback problem.

  4. Brand-new Audacity projects on ASUS2 played normally.

  5. Several other large .aup3 projects outside the Wild Horses project family also appeared to play normally.

  6. The same copied Wild Horses files were opened directly in the current macOS version of Audacity on a MacBook Pro M5. All played without dropouts.

  7. I tested file-copy integrity using SHA-256. With Audacity completely closed, I copied the known-good original .aup3 from the ASUS1 C: drive to the external SSD using Windows Explorer and immediately hashed both files before opening the copy in Audacity.

    The SHA-256 hashes matched exactly.

    Therefore Windows/USB copying can produce a byte-for-byte identical copy.

  8. An older copy had a different SHA-256 hash after it had previously been opened/closed in Audacity. Since .aup3 is a SQLite database and Audacity performs database housekeeping/compaction, I do not know whether that difference is meaningful.

Save As / Backup behavior

This is the strangest and most reproducible observation.

A copied .aup3 that was producing random playback dropouts was opened in Audacity.

  • Using Save Backup to create a new .aup3 on the internal C: drive produced a project that played cleanly.
  • Using Save As on another skipping project also produced a clean-playing project.
  • During one Save As operation, Audacity automatically displayed a project compaction operation lasting about 90 seconds.
  • After these operations, previously troublesome projects sometimes also played normally during that Audacity session.
  • After shutting down/rebooting Windows, the SSD copies again demonstrated the random dropout behavior, while the known-good internal project played normally.

This makes me wonder whether Save As / Backup / database compaction is resetting some internal project or Audacity state.

WAL / SHM observations

While projects are open, Audacity creates the expected:

  • .aup3-wal
  • .aup3-shm

files.

I have not established that these files are responsible, but because the behavior appears related to opening/initializing the project database, I mention them in case they are relevant.

I have also noticed .aup3 modified timestamps changing during this troubleshooting even when I did not intentionally edit the audio, so I have avoided using timestamps as proof that a project was or was not rewritten.

Resource usage

Task Manager does not show obvious resource exhaustion during the dropouts.

Typical values while playing this project were approximately:

  • CPU: 10–20% total
  • RAM: 25–42%
  • Disk utilization: low
  • Audacity CPU usage: generally around 3–10%

No real-time effects are running.

Why I suspect a Windows Audacity issue

The strongest observations are:

  • the source project plays normally;
  • a fresh Explorer copy can be proven byte-for-byte identical by SHA-256;
  • dropouts are random rather than attached to damaged audio locations;
  • exports appear clean;
  • the same copied files play correctly in Audacity on macOS;
  • the symptom has appeared on two different Windows 11 ASUS computers;
  • Save As / Backup / compaction can apparently make the symptom disappear.

The Wild Horses projects were originally created using an earlier Audacity version, so a legacy .aup3 database state interacting with the current Windows version is another possibility.

Not yet tested

I have not yet systematically compared:

  • WASAPI vs MME vs DirectSound;
  • an older Windows version of Audacity;
  • the same projects on a third Windows PC.

Expected behavior

A closed .aup3 copied byte-for-byte to another location should play identically to the original.

Actual behavior

Some copied older .aup3 projects exhibit random non-repeatable playback dropouts under Windows Audacity, while the same files play cleanly under macOS. Creating a new project using Save As or Backup appears capable of clearing the behavior.