You open Audacity on your new Snapdragon laptop, press the red record button, and instead of a waveform you get “Error opening sound device” — or the recording stutters like a scratched CD. The same installer worked flawlessly on your old Intel machine, so the laptop feels broken. It isn’t; the audio chain just needs to be set up with ARM in mind.

Audacity has no official native ARM64 build for Windows, so it runs as an emulated x64 app through Windows’ Prism translation layer. Editing and mixing are perfectly happy under emulation, but real-time audio — recording, live monitoring, effects — is far more sensitive to that extra translation step, to which audio host you select, and to whether Windows is using the laptop maker’s validated audio drivers or a generic fallback.

This guide walks through six fixes in the order a technician would try them: audio host and device selection first, then sample rates and latency, then the two big error messages, then plugins and the FFmpeg library, and finally the driver layer. Test recording after each fix — most people stop at fix two or three.

Why this happens

  • Emulated x64 build under Prism: With no native ARM64 Audacity, real-time audio threads pay a translation cost that native apps never see, which shows up as latency and dropouts first.
  • Wrong audio host selected: Audacity defaults to MME, the oldest and slowest host; WASAPI is the host that talks to modern ARM audio drivers cleanly and with far lower latency.
  • Sample rate mismatch: A project running at 44100 Hz talking to a device locked at 48000 Hz is a classic source of device errors, pitch weirdness, and garbled recordings.
  • Exclusive-mode conflicts: Another app — a browser tab, Teams, a game — holding the microphone or speakers in exclusive mode blocks Audacity with the generic “error opening sound device” message.
  • Architecture-mismatched plugins: ARM64-native VST3 plugins cannot load into the emulated x64 Audacity process, and a bad plugin scan can crash the plugin manager on every launch.
  • Generic OEM audio driver: Windows Update’s generic High Definition Audio driver lacks the Snapdragon audio DSP features and quirks fixes that the laptop maker’s validated driver provides.

How to fix it

Work through these in order — diagnose first, then act.

Fix 1: Choose WASAPI and the correct device

The single biggest win on ARM laptops: Audacity defaults to MME, the oldest, slowest audio host Windows offers. Switching to WASAPI and naming your devices explicitly gives lower latency and far fewer device errors, and it takes under a minute.

  1. Open Audacity and find the Audio Setup toolbar — set Audio Host to WASAPI, not MME or Windows DirectSound.
  2. Set Recording Device to your actual microphone or interface by its real name, never “Microsoft Sound Mapper - Input.”
  3. Set Playback Device to your speakers or headphones explicitly for the same reason — mappers guess, and they guess wrong on ARM.
  4. Press record for ten seconds and check the waveform is clean — if the error is gone, stop here.
  5. If the device list is empty or wrong, restart Audacity after plugging the device in; hot-plugged devices sometimes don’t appear until relaunch.

Fix 2: Match sample rates everywhere

A project running at one sample rate while the device is locked to another is a classic source of errors and garbled recordings. Windows, the device, and Audacity must all agree — check all three.

  1. Look at Audacity’s bottom-left status bar and note the Project Rate — set it to 48000 Hz, the standard for most USB interfaces and laptop microphones.
  2. Right-click the speaker icon in the taskbar, open Sound settings > More sound settings, and open your recording device’s Properties.
  3. On the Advanced tab, set Default Format to match — “2 channel, 16 bit, 48000 Hz” or the 24-bit equivalent your device offers.
  4. Do the same for the playback device so monitoring doesn’t resample mid-stream and introduce its own glitches.
  5. Restart Audacity and record again; resampling clicks and speed weirdness should be gone.

Fix 3: Reduce latency with buffer settings

Under emulation, the default audio buffer that feels fine on x64 can cause dropouts on ARM. Tuning the buffer and switching off real-time extras brings latency down to a workable range for overdubs and monitoring.

  1. Open Edit > Preferences > Devices and set the buffer length to around 100 ms as a starting point.
  2. If you hear dropouts, raise it in 25 ms steps; if latency feels laggy while monitoring, lower it — small changes, testing each time.
  3. In Preferences > Recording, turn off “Software Playthrough of input” unless you truly need live monitoring — it doubles the real-time workload.
  4. Close the browser, Teams, and any app making sound during takes — background audio streams fight Audacity for the device and the CPU. For long plugged-in sessions, a battery limiter at 80 percent also keeps heat down while the charger stays connected.
  5. Record a one-minute test and listen end to end for clicks or gaps before committing to real work.

Fix 4: Fix “Error opening sound device”

This is Audacity’s generic “I can’t reach the device” message, and it has a short list of usual suspects. Work through them in this order and it resolves in minutes.

  1. Close every other app that might hold the microphone — browsers with open tabs, Zoom, Discord, Xbox Game Bar.
  2. In the device’s Properties > Advanced tab, uncheck “Allow applications to take exclusive control of this device” so one app can’t lock the rest out.
  3. Switch the Audacity host to WASAPI if you haven’t already — MME fails outright on devices that only expose proper WASAPI endpoints.
  4. Try a different USB port for external interfaces; some ARM laptops only fully power certain ports, and an underpowered port produces exactly this error.
  5. As a last resort, uninstall the device in Device Manager (checking “attempt to remove the driver”) and let Windows rediscover it on restart.

Fix 5: Sort out plugins and the FFmpeg library

Plugin scans are the other classic crash point: Audacity runs emulated, so only x64 plugins load, and the optional FFmpeg import library must match the emulated architecture too — not ARM64.

  1. Open Tools > Plugin Manager and look for failed VST3 entries — remove or relocate any ARM64-native plugins; they will never load in the emulated process.
  2. Keep one clean VST3 folder and point Audacity at it in Preferences > Effects, then rescan so there’s exactly one source of truth.
  3. If MP3 or M4A import fails, install the 64-bit FFmpeg build (matching Audacity’s emulated x64 architecture, not ARM64) and point Audacity at it in Preferences > Libraries.
  4. Disable rescanning on every startup once the set is stable, so a single bad plugin can’t break every launch.
  5. If the manager itself crashes, delete pluginregistry.cfg and pluginsettings.cfg from %AppData%\audacity to reset the scan state completely.

Fix 6: Update the OEM audio driver and check firmware

If everything above is correct and problems persist, the driver is suspect — Windows Update’s generic audio driver is a common culprit on Snapdragon machines, and it’s invisible until you look.

  1. Open Device Manager > Sound, video and game controllers and check whether the device shows the maker’s name or just “High Definition Audio Device” — the generic name is the tell.
  2. Download the latest audio driver for your exact model from Dell , HP , or Lenovo support — the same OEM-first routine as the Adreno driver update guide .
  3. Install as administrator, restart, and recheck the device name in Device Manager to confirm the real driver loaded.
  4. While on the support page, check for a BIOS or firmware update too — the quick NPU firmware version check shows where makers hide these, and audio DSP fixes often ride along with firmware.
  5. If Windows Update swaps the driver again later, Microsoft’s Windows support pages document the supported way to block a specific driver update.

Closing

Audacity on ARM is a configuration problem, not a compatibility dead end — WASAPI plus matched sample rates fixes the majority of cases, buffer tuning handles the rest, and OEM drivers finish the job. Get those three right and the Snapdragon laptop records as cleanly as the Intel machine it replaced.

Frequently asked questions

Is there a native ARM64 version of Audacity for Windows?
Audacity does not ship an official native ARM64 build for Windows, so on Snapdragon and other ARM laptops it runs as an emulated x64 app through Windows’ Prism layer. Editing and mixing work fine under emulation, but real-time recording and effects pass through the translation layer, which is why latency and audio-device quirks show up more on ARM than on x64 machines.
Why does Audacity say 'Error opening sound device' on my Copilot+ PC?
This usually means the selected host and device disagree — for example, the WASAPI host pointing at a device another app has locked in exclusive mode, or the project’s sample rate not matching the device’s default format. Reselecting the host, picking the device by name, and matching the sample rates on both sides fixes it in most cases.
Why is recording latency so high on my ARM laptop?
Emulated audio processing adds overhead that native apps don’t pay, and the default buffer settings assume an x64 machine. Switching the audio host to WASAPI, tuning the buffer length in Preferences, and turning off software playthrough of the input brings latency back into a usable range for most recording work.
Do Audacity plugins work on Windows on ARM?
Built-in and Nyquist plugins work normally. VST and VST3 plugins must match the architecture Audacity itself runs as — under emulation that means x64 plugins load fine, while ARM64-native plugins will not load and can crash the plugin scan. The optional FFmpeg import library must likewise be the 64-bit build, not an ARM64 one.