// BEYOND PLUGINS
Custom Audio Software Engineering
Custom audio software is a standalone application, DSP library, or mobile app that processes audio in real time. We build those in C++ and JUCE for macOS, Windows, Linux, iOS, and Android: sample editors, synthesizers, audio engines, and the device I/O underneath them. We agree the latency budget before implementation starts.
Standalone Desktop Apps
Cross-platform desktop applications for macOS, Windows, and Linux built with JUCE: sample editors, synthesizers, utilities, and tools that host plugins themselves.
DSP Algorithm Design
Analog circuit modelling, filter design, oversampling, and time-stretching written in C++ so the same algorithm runs in your application and your plugins.
iOS and Android Audio Apps
Low-latency recording and playback through AVAudioSession on iOS and AAudio or Oboe on Android, with one shared C++ engine under the native interface.
Device I/O and Audio Backends
CoreAudio on macOS, ASIO and WASAPI on Windows, ALSA and JACK on Linux: device enumeration, sample-rate negotiation, and recovery when a user unplugs an interface mid-session.
DAW Integration and Scripting
Ableton Live Remote Scripts, Pro Tools PTSL automation, and MIDI or OSC control surfaces, so your software drives the DAW your users already work in.
Packaging and Distribution
Signed .dmg and .pkg packages with macOS notarization, signed Windows installers, TestFlight and App Store submission, and Android app bundles.
// THE TECHNICAL GAP
Why do general app agencies fail at audio?
The audio callback is not a background task
Real-time audio runs in a callback owned by CoreAudio, WASAPI, or AAudio, and every layer between your code and that callback costs latency. Electron, React Native, and garbage-collected runtimes pause at the moment a user is recording a take. The engine has to be native C++; the interface can be whatever your team already builds well.
Hardware misbehaves in the field
Users change sample rate mid-session, unplug interfaces, pair Bluetooth headphones, and open your app while a video call already owns the microphone. CoreAudio, WASAPI, ALSA, and AAudio each report those events differently. Handling them is most of the work in a dependable audio application and almost none of the work in a demo.
How we work the problem
We write the engine once in C++ and bind it to each platform's audio API directly, against a latency and CPU budget agreed before implementation. Device changes, xruns, and session interruptions each get explicit handling and a test case before release.
// ENGAGEMENT
How does an audio software project run?
Every stage produces something you can run or hand to another developer.
Scope and latency budget
A written proposal with the feature list, target platforms, milestones, and an agreed latency and CPU budget: buffer size, round-trip target, and the hardware we test against.
Engine architecture
A short architecture document: the C++ engine boundary, threading model, file and project formats, and how the interface talks to audio. Every later decision rests on it.
Prototype on real hardware
A runnable build on your primary platform that records, plays, and processes audio end to end, with the measured round-trip latency reported on your own interface.
Milestone builds
Signed macOS and Windows builds, TestFlight builds for iOS, and a plain-language changelog at each milestone, with the latency and CPU figures measured again.
Release and handover
Notarized installers, store submissions where relevant, the CMake project and CI workflow, and a release checklist, all in your repository.
// WHAT YOU RECEIVE
What platforms and packages do you deliver?
Platforms and packages
You receive macOS .dmg or .pkg as a universal binary, signed Windows installers, Linux builds as AppImage or .deb where a project needs them, iOS builds through TestFlight and the App Store, and Android app bundles. One C++ core serves all of them.
Signing, notarization, and store review
macOS builds are signed with your Developer ID, notarized, and stapled. Windows installers are signed with your certificate. We prepare App Store and Play Store submissions, including the microphone usage strings and background audio entitlements that reviewers check first.
Source, tests, and CI
You receive the CMake project, the CI workflow that produces every package, and the test harness we use to verify latency and device handling. Your team can cut a release without us.
// WHAT GOES WRONG
Pitfalls We Design Around
Device and Sample-Rate Changes
A user moves from 44.1 kHz to 48 kHz or unplugs an interface, and the engine has to rebuild its graph without losing the session. Untested, this is the most common crash in desktop audio software.
Latency Budgets Set Too Late
Round-trip latency is the sum of buffer size, resampling, and every queue in between. Finding out at beta that the architecture costs 40 ms is a rewrite, so the budget is agreed during scoping.
Work on the Render Callback
File reads, JSON parsing, and UI notifications inside the callback cause xruns. Disk streaming belongs on a reader thread with a lock-free ring buffer feeding the audio engine.
Mobile Interruptions
A phone call, a Bluetooth switch, or a locked screen suspends audio. AVAudioSession on iOS and audio focus on Android need explicit handling, or your users lose half a recording.
Signing and Permissions
An unnotarized macOS app will not open on a customer's machine, and a missing microphone usage string fails App Store review. Both belong in CI rather than in release week.
Builds Tied to One Machine
When a release can only be produced on one laptop, the product stops when that laptop does. CMake with a CI matrix for macOS, Windows, and Linux keeps releases reproducible.
// SHIPPED WORK
Applications We Built
CLIENT: LATENCYFIX
LatencyFix
End-to-end development including Ableton Remote Scripts, Pro Tools PTSL automation, and product UI implementation. The result is a remote recording workflow that keeps DAW sessions aligned and reduces friction for distributed collaboration. The work spans two host integrations, Ableton Live and Pro Tools, outside any plugin format.
CLIENT: DJAMINN
Djaminn App
Audio-video synchronization development and targeted improvements to the app's audio engine, giving a tighter mobile collaboration experience with more reliable media playback and recording alignment. On a mobile app like this, the timing between the audio and video streams is the product.
CLIENT: AUDIOMODERN
Playbeat 4 Standalone
End-to-end development of the full application and sequence randomization engine in JUCE and C++. Alongside the plugin formats, Playbeat 4 ships as a standalone application on Windows and macOS and on iPadOS, where the same codebase owns device I/O, file storage, and touch input.
// FIT
When We Are Not the Right Choice
We are not a full-service studio. If the audio in your product is a thin layer over a web stack, or you need brand design, marketing, and a backend team as well, another supplier will serve you better and we will say so on the first call. Device driver work, such as an ASIO driver or a macOS HAL plugin, also sits outside what we take on.
// FAQ
Common Questions
What platforms do you develop for?
macOS, Windows, Linux, iOS, and Android. Our C++ and JUCE-based approach gives us broad platform reach from a single codebase where applicable.
Can you integrate with our existing backend or APIs?
Yes. We handle REST and WebSocket integrations, cloud sync, and backend connectivity as part of full-stack audio application work.
What separates you from a general app development agency?
We specialize exclusively in real-time audio. General agencies rely on high-level wrappers that introduce latency and audio dropouts. We write native, hardware-accelerated code where audio correctness is non-negotiable.
Do you handle code signing and deployment?
Yes, including code signing, macOS notarization, and installer packaging for Windows and macOS. We can guide you through app store submission as well.
Do you sign NDAs?
Yes, NDAs and white-label arrangements are standard. All engagements are confidential by default.
Can one codebase serve the desktop app and the plugin version?
Usually, yes. We keep the DSP and engine in a shared C++ library and build the standalone application, the VST3, AU, and AAX plugins, and the iPadOS version from the same project. Playbeat 4 for Audiomodern ships that way.
How low can the latency go?
On desktop with a dedicated audio interface, a few milliseconds of round-trip latency is realistic at 64 to 128 samples. On iOS the hardware sets a higher floor, and on Android it varies by device. We measure on your target hardware during the prototype stage and report the figure in writing.
// RELATED SERVICES