Install

Every release publishes five desktop downloads, a command-line binary and the DAW plugin on its own. Pick the one for your machine; there is nothing else to set up. The two tablet builds are the exception and come from a store — see iPadOS and Android for why there is nothing here to download.

Three of them install the plugin for you, behind a checkbox that starts ticked. If you use a DAW, those are the ones to take.

The AppImage and the flatpak cannot install a plugin, and that is a property of the formats rather than something left undone: an AppImage never installs anything, and a flatpak’s plugin would be built against the sandbox’s libraries while the DAW that has to load it runs on the host’s. If you want the plugin on Linux, take the tarball.

Releases are on the releases page.

The periods in those names are GitHub’s: the build calls the file Open Audio Analyzer-<version>-… and GitHub replaces the spaces when it publishes it, so a file you download is dot-separated and one you build yourself is not. The AppImage is the exception and is built with the dots already in its name, because its update file refers to it by name.

macOS

Open the pkg and follow it through. It opens on its customisation pane, with three rows:

Untick either plug-in row if you do not want it. The application row is fixed because the plug-ins have nothing to talk to without it — they stream what they measure to the app over loopback, on the same machine.

The application and both plug-ins need macOS 14.2 or later, so there is no longer a version that can run one and not the others. Below it the installer declines rather than placing files that could not load.

The installer needs an administrator password, because /Library/Audio/Plug-Ins is shared by every user and every DAW on the machine.

There is no uninstaller. macOS packages do not come with one. To remove everything:

sudo rm -rf "/Applications/Open Audio Analyzer.app" \
  "/Library/Audio/Plug-Ins/VST3/Open Audio Analyzer.vst3" \
  "/Library/Audio/Plug-Ins/Components/Open Audio Analyzer.component"

Your presets, skins and settings live in ~/Library/Application Support and are left alone by that.

Open Audio Analyzer will ask for microphone permission the first time you choose a capture device. macOS treats any audio input as the microphone, including a loopback device carrying your DAW’s output. Declining it leaves Open Audio Analyzer with the test tone and silence, and the reason is shown rather than logged.

Open Audio Analyzer will ask for local network permission the first time you publish to a tablet, and it needs it to announce itself. Declining leaves the port open and the announcement blocked, so the desktop says it is publishing and no tablet ever lists it. A tablet given the address by hand still connects and works.

Open Audio Analyzer will ask for camera permission the first time you scan a pairing code, and only then — nothing else in the application uses a camera. The image is examined for a code and is never recorded, stored or sent anywhere. Declining leaves the other two ways of finding a host untouched, and the panel names the setting to change rather than showing a black rectangle.

Upgrading from 0.5.0 or earlier revokes every permission the application holds, because 0.6.0 changed the bundle identifier from dev.openaudioanalyzer.oaa to com.openaudioanalyzer.oaa, and macOS keys a permission to the identifier rather than to the application. That is Local Network, Microphone, Camera and — the one that fails without saying so — System Audio Recording. Each old entry under System Settings → Privacy & Security belongs to an application that no longer exists; allow the new one in each. Nothing else about the upgrade needs anything: presets, skins and paired hosts are keyed by name rather than by identifier and are all still there.

System audio is the one to check first, because it is the only one of the four whose refusal is silent — see below.

There is no Mac App Store build and there will not be one. The store requires the app sandbox, which would move your presets, skins and delivery targets into a private container you cannot open. Open Audio Analyzer is distributed directly, signed with a Developer ID and notarised.

System audio

There is nothing to install. Pick System Output from the source menu in the status bar — it is the first entry, and it is named after the output device it is metering, so you can see what you are listening to. Open Audio Analyzer measures what is being sent to that device without rerouting anything, so your audio keeps coming out of the speakers while it is being metered.

This is a Core Audio process tap rather than a driver, which is why there is no installer, no password prompt and no reboot.

Three things worth knowing:

• macOS may ask for permission to record system audio the first time you choose it. If you decline, the tap delivers silence rather than an error, so the meters sit at the floor — which looks exactly like genuinely quiet audio. Apple designed the refusal to be undetectable, so there is no error for Open Audio Analyzer to show you.

  If the meters sit at the floor with something obviously playing, look under System Settings → Privacy & Security → System Audio Recording. Two things put an application there that cannot use it: declining once (the prompt does not come back on its own), and upgrading from 0.5.0 or earlier, which changed the bundle identifier and left the old grant naming an application that no longer exists — so the list can show an “Open Audio Analyzer” that is switched on while the one you are running has never been asked about. Remove the stale entry, then choose System Output again to raise a fresh prompt.

• It follows your output device when you change it, as long as the new one has the same sample rate and channel count. Swapping between two stereo devices at 48 kHz — speakers and headphones, say — just works. A device with a different format stops the tap instead, because the meters are built around one format and cannot be rebuilt mid-measurement; choose the source again to pick the new device up.

• It captures every application at once, mixed as your output device receives it. There is no per-application selection.

macOS 14.2 is where the tapping API arrived, and it is also Open Audio Analyzer’s minimum, so there is no supported version where the entry is missing. The loopback route older versions needed — a Multi-Output Device in Audio MIDI Setup pairing your real output with BlackHole, or an interface with a loopback channel — still works and is still a perfectly good way to meter one specific path, but nothing requires it any more.

If you are metering a DAW, the plugin is better than any of these: it takes the buffer directly and brings the transport with it.

Windows

Run the .exe. On the Select Components page:

The installer needs administrator rights for both of those, and it registers an uninstaller under Settings → Apps → Installed apps, which removes the plug-in too.

Windows will warn you before it runs. SmartScreen shows “Windows protected your PC”; click More info → Run anyway. Windows may also flag the download in your browser first. That is the current state of the installer and not a sign that something is wrong with the file — releases are not yet signed, and a certificate would not clear the warning immediately anyway, because SmartScreen goes by a reputation a download has to accumulate. Verify the file against the checksums on the release page if you want certainty.

Open Audio Analyzer asks for microphone permission on first use of a capture device, and Windows may also need it enabled under Settings → Privacy → Microphone for desktop apps.

For system audio, use a WASAPI loopback-capable device or a virtual cable such as VB-Audio Cable.

Linux

Tarball

The only Linux download that carries the plugin, and the one to take if you use a DAW.

tar -xzf Open.Audio.Analyzer-0.11.0-linux-x86_64.tar.gz
cd "Open Audio Analyzer-0.11.0-linux-x86_64"
./install.sh

It asks one question — whether to install the VST3 into ~/.vst3 as well — and the default is yes. Nothing here needs root: the application goes to ~/.local/share, the desktop entry and icons to ~/.local/share, and every DAW searches ~/.vst3 without being told to.

./install.sh --no-vst3        # application only, no question asked
./install.sh --vst3           # both, no question asked
sudo ./install.sh --system    # /opt and /usr/lib/vst3, for every user
./install.sh --uninstall      # removes what it installed

Piped or run from a script it takes the default rather than waiting for an answer that is never coming. The uninstaller is a copy of the same script, left next to what it installed.

AppImage

chmod +x Open.Audio.Analyzer-0.11.0-x86_64.AppImage
./Open.Audio.Analyzer-0.11.0-x86_64.AppImage

GTK 3 is expected from the host — every desktop Linux that can run a Flutter application already has it — and everything else travels inside the file. It is built on the oldest distribution the project supports, so it starts on newer ones as well.

An AppImage from any release after 0.16.0 carries update information, so AppImageUpdate, or a tool built on it, can replace it with the newest release and downloads only the parts that changed. 0.16.0 and earlier carry none: moving off one of those means downloading the new file once.

Flatpak

flatpak install --user Open.Audio.Analyzer-0.11.0-x86_64.flatpak
flatpak run com.openaudioanalyzer.oaa

The flatpak carries its own runtime, so it does not depend on the host’s libraries at all. It is granted audio, network and filesystem access — the manifest says why for each.

For system audio on either, PipeWire’s own loopback or pactl load-module module-null-sink gives you a monitor source Open Audio Analyzer can open.

iPadOS

The iPad build is the same application as the desktop one: the same canvas of meter modules, the same engine compiled in behind them, the same painters drawing them. It measures an input on the iPad itself, and it can draw another machine’s meters over the local network instead — Remote display covers how the two find each other. Neither is a cut-down version of the other.

It needs iPadOS 15 or later, which costs no device: iPadOS 13, 14 and 15 run on the same iPads — every model back to the Air 2 and the mini 4 — so if yours could run it before, it can still run it after updating.

The quickest of the three ways is the camera: on the desktop, the code button beside PUBLISH in the menu bar; on the iPad, Scan a QR code. iPadOS asks for camera permission the first time, and refusing it leaves the host list and the typed address exactly as they were.

It is free on the App Store, and there is no IPA on the releases page — which is not an oversight. An App Store signature provisions no devices, so an IPA you downloaded could not be installed on your iPad by you or by anybody else; there is no file here that would do you any good.

The store carries the build that has cleared review, and that is not always the version the desktop downloads are on. TestFlight is where a tagged release lands first — every one of them uploads a build, before Apple has looked at it — so ask on the repository if you want the newest one ahead of the store. Or build it yourself, which needs a Mac with Xcode and no credentials beyond a free Apple ID:

flutter run -d <your ipad>    # `flutter devices` names it

A USB cable works as well as the network. Open Open Audio Analyzer on the iPad and plug it into a desktop that is publishing; the iPad shows the desktop under Over USB in ATTACH. Nothing is switched on on either side: the desktop reaches the iPad through the same Apple service Finder syncs it with, which macOS has built in, Linux has as usbmuxd (packaged by most distributions), and Windows has with iTunes or the Apple Devices app. Accept Trust This Computer on the iPad the first time. The application has to be open on the iPad for the desktop to find it.

Android

The Android build is the same application as the desktop one — the same canvas, the same modules, the same engine compiled into it. It measures an input on the tablet itself, and it can draw another machine’s meters over the local network instead; Remote display covers how the two find each other. Neither is a cut-down version of the other.

Before 0.12.1 there was no live input on Android, because the manifest declared no RECORD_AUDIO and Android will not open a microphone without it. Everything above it worked, which is why the platform was described here as a display rather than an analyser — it looked like a design and it was an omission.

It is distributed through Google Play, and there is no .apk on the releases page. What a tagged release builds is an .aab, a publishing format rather than an installable file: Play generates the download from it per device and signs it with a key Google holds. There is nothing here you could install.

Play offers it to tablets only. It asks for a shortest screen edge of 600dp, which a 7-inch tablet is above and a handset is not, so a phone does not find the app in the store at all; an unfolded foldable is over the line and eligible. The canvas is a grid of meter modules with a scale down each side, and there is no phone-sized arrangement of that worth reading. Nothing about how the application behaves changes either way.

Every tagged release uploads a build to Play, and it is a closed test. That has two consequences worth knowing before you try to install it.

The listing is not public. play.google.com/store/apps/details?id=com.openaudioanalyzer.oaa is not findable by search and does not resolve for an account that is not testing it.

The opt-in link is not an invitation. A closed test grants access by list: Play only lets an account opt in if that account is already on the track’s tester list — an email list or a Google Group the developer has added. Opting in is the second step, never the first, so the link below does nothing on its own for an account nobody has added yet.

So it is two steps, in this order:

1. Ask to be added — open an issue on the repository with the Google account address you use on the tablet. It has to be that account: Play matches the tester list against the account signed in to the Play Store, not against whoever opened the link.

2. Opt in, once you have been added. Play gives the test two links and they are not interchangeable — use the one that matches what you are reading this on:

   Where you are	Link
   A browser, on any machine	Opt in on the web
   The Android tablet itself	Open it in the Play Store

   The Google Play badge on the front page leads to the same instructions, which is where to send anybody who asks how to get in.

Changes to a tester list can take a few hours to reach the store, so if the listing still refuses you immediately after being added, that is why.

Building it yourself needs the Android SDK and no credentials at all, and the filter above does not apply — it is the store’s, so flutter run puts the build on whatever device you name:

flutter run -d <your device>    # `flutter devices` names it

Three permissions it asks for, and one it does not. The microphone is the input it measures, asked for when you first choose one rather than at launch — so a tablet that only ever mirrors another machine is never asked, and refusing leaves whatever was playing alone. The camera is for the QR scanner in the host picker, asked for the first time you open it; refusing leaves the host list and the typed address exactly as they were. Multicast is an install-time permission with no dialog, and it is what lets the tablet see a desktop publishing on the network. NEARBY_WIFI_DEVICES is deliberately not declared: it covers scanning and managing networks, which this application never does.

A USB cable works as well as the network, and is the thing to try when the Wi-Fi is slow. On a Mac or a Linux desktop it needs nothing switched on: while PUBLISH is on, plug the tablet in, and Android asks whether to open Open Audio Analyzer for the USB accessory — say yes, tick always if you like, and the tablet shows the desktop under Over USB in ATTACH, with Settings › Publish naming the tablet. While the cable is in, the tablet is the desktop’s accessory rather than a drive, so its files are not offered to the desktop until it is unplugged. A device is asked once each time it is plugged in.

On Windows, or with USB debugging already on, the other route still works: with USB debugging switched on under the tablet’s Developer options and the Android SDK’s platform tools — adb — on the desktop, in the SDK’s usual place or on ANDROID_HOME, the desktop forwards its display port down the cable. USB tethering works too and needs neither: a desktop found over it is listed in the same place. Nothing new is asked for by any of them — the cable reaches the same port the network does.

In a DAW

The plugin is a VST3 and an Audio Unit that draw nothing. They measure the buffer your DAW gives them and stream it to the desktop application, which displays it — so the app has to be running, and the plugin finds it by itself on 127.0.0.1:47822 whichever of the two you start first.

It has been tested in Ableton Live, Logic Pro, Cubase, FL Studio and Studio One — Logic through the Audio Unit, the others through the VST3 — and it accepts any track or bus from mono to 7.1.

There is an AAX for Pro Tools as well, in the oaa-plugin-<platform> archive and in none of the installers. It is not yet signed for Pro Tools — see below.

The installers above do this for you — the macOS pkg, the Windows .exe and the Linux tarball each carry the plugin and put it where your DAW looks, so everything in this section is the manual route. Take it if you are installing the plugin on a machine that already has the application, or if you deliberately took the AppImage or the flatpak.

oaa-plugin-<platform> is an archive, not an installer. Copy the bundle — the .vst3, .component or .aaxplugin itself, not the directory holding it — into the folder your DAW scans. On a machine that has never had a plugin installed, that folder does not exist yet:

Pro Tools has no per-user plugin folder, which is why the AAX column names a machine-wide path on both platforms.

The installers use the machine-wide equivalents of those — /Library/Audio/… on macOS, C:\Program Files\Common Files\VST3 on Windows — which every DAW scans as well. The per-user paths above are what you can write without a password.

# macOS
mkdir -p ~/Library/Audio/Plug-Ins/VST3 ~/Library/Audio/Plug-Ins/Components
cp -R "VST3/Open Audio Analyzer.vst3"    ~/Library/Audio/Plug-Ins/VST3/
cp -R "AU/Open Audio Analyzer.component" ~/Library/Audio/Plug-Ins/Components/
xattr -dr com.apple.quarantine \
  ~/Library/Audio/Plug-Ins/VST3/"Open Audio Analyzer.vst3" \
  ~/Library/Audio/Plug-Ins/Components/"Open Audio Analyzer.component"

The xattr line is not optional on macOS. Your browser marks every file it downloads, the mark survives being unpacked, and Gatekeeper then refuses to load the bundle. What the refusal looks like depends on which macOS you are on, and neither version of it names the real problem:

• macOS 15 and later put up a modal — “Apple could not verify ‘Open Audio Analyzer.vst3’ is free of malware that may harm your Mac”, or on some versions “will damage your computer. You should move it to the Trash” — and there is nothing in System Settings to override it with. The “Open Anyway” button under Privacy & Security is only ever populated for a blocked launch. A plugin is loaded into your DAW, which is a library load, so no button ever appears and the dialog’s only other choice is Move to Trash. The xattr line is the only way past it.
• Earlier versions fail silently instead. The plugin is simply absent from the DAW’s browser with nothing logged and no message anywhere, which is indistinguishable from having copied it to the wrong folder.

A plugin you built yourself has no flag to remove. A downloaded one needs either the line above or a notarised bundle — a Developer ID signature alone does not clear the flag, which is the part that surprises people. Whether a given release is notarised depends on whether the signing credentials were present when it was built, and xattr works either way.

None of this applies to the pkg. Files placed by an installer are not quarantined, so a plugin installed that way carries no flag to remove — which is the second reason the pkg exists.

The AAX and Pro Tools

The AAX bundle is built and is not signed, and a released Pro Tools will not load it. This is not the quarantine flag above and xattr does not help.

An AAX plugin needs a signature from PACE’s wraptool, made against an Avid developer account that holds a signing certificate. That is a separate thing from the code signature every bundle in this archive already carries, and Open Audio Analyzer does not have the certificate yet. Without it the plugin loads in a Developer build of Pro Tools and in Avid’s own developer tools, and nowhere else.

Pro Tools does not explain the refusal. The plugin is simply not in the insert menu — the same thing you would see if you had copied it to the wrong folder, or not copied it at all.

That is why it is in the archive and not in any installer: a ticked checkbox that installs something no DAW will show you is worse than no checkbox. When the certificate exists, the AAX will be installed the way the VST3 and the Audio Unit already are, and this section will say so.

Ableton Live also has to be told to look there — Preferences → Plug-Ins → Use VST3 Plug-In System Folders. It then appears under Open Audio Analyzer. Live rescans on launch; a plugin copied in while it is open needs a restart.

Insert it on a track, a bus or the master. Its own window is a status panel and nothing else — the meters are in the app, and the panel says so. What it shows is a diagram of the three places the path can break: the host’s audio, the host’s playhead, and the socket to the app. Each run is lit when something is travelling down it and dark when nothing is, and the socket’s dashes move while frames are being sent, so a link that has quietly stopped does not look like one that is working. Under it, the sample rate and channel count the host is giving it, how long it has been measuring, the integrated loudness, and one line naming whatever is wrong. Several inserts can be connected at once, and each is a row in the app’s source picker — DAW plugin — Logic Pro, beside the test tone and the machine’s own inputs. The first one to connect selects itself, because inserting it is the act of choosing it; after that the source is whatever you last chose, so a plugin left in a session no longer stands between you and your interface. Choosing a DAW releases the capture device, and the selection is remembered between launches.

The host’s transport comes across with the audio, so the app’s status bar reads back the DAW’s position, tempo and time signature, and relays them to an attached tablet.

The command-line analyser

oaa needs no Flutter runtime and nothing installed. It is an archive of two files — the executable and the engine as a shared library beside it — and the executable finds the library by its own location, so keep them together and link to the executable rather than copying it out:

tar -xzf oaa-cli-Linux.tar.gz -C ~/.local/opt/oaa
sudo ln -s ~/.local/opt/oaa/bin/oaa /usr/local/bin/oaa

It is the same measurement code the application runs. See Analysing files.

Where Open Audio Analyzer keeps your configuration

Settings, presets, delivery targets and skins are plain JSON, one file each, in a directory you can read, edit, copy between machines and put in a repository:

The two tablets are the exception to “a directory you can read”: both systems give an app a private directory, so the files are on the device but not reachable from a file manager or from a desktop. Settings → Session prints the path. Android’s comes from getFilesDir(), because nothing in an Android process names a directory it is allowed to write to, and it is removed with the app.

Two overrides, in order of precedence:

oaa --config-dir /path/to/config     # or the application, via --config-dir
export OAA_CONFIG_DIR=/path/to/config

The flag wins over the variable, and the variable wins over the convention. On macOS the flag is the one that works for a .app: passing an environment variable means launching the binary inside the bundle, and a bare binary launch changes how macOS attributes the microphone request — so the variable and device capture cannot be used in the same run.

open -a "/Applications/Open Audio Analyzer.app" --args --config-dir=/path/to/config

Uninstalling

Open Audio Analyzer writes nothing outside the configuration directory above. Delete the application, delete that directory, and nothing of it remains.