App audio vs. system audio: What should a desktop meeting recorder capture?
If you're building a desktop meeting recorder, one of the first technical decisions is how to capture audio from the user's computer. We compare system audio, app audio, and why capturing the right source matters.
At first, system audio capture seems like the obvious solution for meeting recording. Record everything the computer is playing, capture the user's microphone separately, and combine the two streams.
That can work for a simple recording prototype. But for a production meeting recorder, capturing all system audio introduces an important problem: your recorder doesn't necessarily know which audio belongs to the meeting.
For a production meeting recorder, the goal is to capture the audio that belongs to the meeting rather than every sound produced by the computer. That usually means isolating the meeting application’s outgoing audio, capturing the local microphone separately, and keeping those streams synchronized and echo-cancelled. A Desktop Recording SDK handles this meeting-specific audio capture across macOS and Windows.
What is system audio?
System audio is the combined audio being played by a computer. It can contain audio from multiple applications at the same time, including the meeting, notifications, music, videos, and other browser tabs.
Depending on the operating system and capture method, that can include audio from:
- Zoom, Google Meet, or Microsoft Teams
- Spotify or Apple Music
- YouTube videos
- Slack or other notification sounds
- Another browser tab
- Another call happening at the same time
System audio is useful when your goal is literally to record everything the computer is playing.
Developers usually do not want system audio from a meeting recorder, as this method can introduce distracting content and reduce the overall quality of the recording.
What is app audio?
App audio is audio associated with a particular application or process rather than the entire computer.
Instead of asking:
"What audio is this computer playing?"
you're effectively asking:
"What audio is coming from the application where this meeting is happening?"
For example, if someone is taking a Zoom call while music is playing in Spotify, app-level capture can help isolate the meeting audio rather than recording both.
For a meeting recorder, capturing application audio is the behavior you actually want.
System audio vs. app audio
| System audio | App audio | |
|---|---|---|
| What it captures | Audio playing across the computer | Audio associated with a selected app or process |
| Meeting audio | Yes | Yes |
| Unrelated audio | Included | Excluded |
| Best fit | General-purpose screen/audio recording | Application-specific recording, including meetings |
The biggest difference is scope.
If your user receives a notification, opens a YouTube video, or plays music during a meeting, a system-wide recording can potentially include those sounds. An app-specific recorder has a much better opportunity to capture only the content relevant to the conversation.
Why capturing system audio isn't enough for a desktop meeting recorder
Isolating the right audio source is only the beginning.
A meeting recorder has to turn several independent signals into one reliable representation of a conversation.
1. You need both sides of the conversation
The meeting application normally plays the remote participants' audio, while the local participant speaks through their microphone.
Capturing system audio alone therefore doesn't capture the complete conversation. Your application also needs to capture microphone input.
And once those two sources are captured separately, they need to be combined correctly.
2. Unrelated audio can make its way into the recording
Recording all system audio means you might capture more than just the meeting.
A notification sound is mostly an annoyance. Capturing audio from another application, however, can create privacy problems as well as lower the quality of recordings and transcripts.
For a dedicated meeting recorder, the ideal behavior is straightforward: record the meeting, not the user's entire computer.
3. Microphone and meeting audio have to stay synchronized
Capturing the microphone and outgoing application audio through different APIs creates another challenge: synchronization.
Microphone audio and outgoing meeting audio can come from different capture APIs, each with its own timestamps, sample rates, buffer sizes, clock sources, and processing latency. If they drift apart, participants may talk over one another in the final recording even though the actual conversation sounded normal.
Recall.ai's Desktop Recording SDK handles synchronization between microphone and outgoing meeting audio rather than requiring developers to build and maintain that pipeline themselves.
4. You have to account for echo
Imagine a remote participant speaks through your laptop speakers.
Your system or app audio capture records their voice directly. But your microphone may also hear that same voice coming out of the speakers.
Now the remote participant exists twice in the recording.
A production recorder needs acoustic echo cancellation to recognize and remove this duplication. Recall's Desktop Recording SDK includes echo cancellation as part of its audio pipeline.
5. A meeting recorder needs to understand the meeting
An audio stream doesn't tell you much about the context surrounding it.
A useful meeting recorder also needs to answer questions such as:
- Did a meeting just start?
- Which window should be recorded?
- When did the meeting end?
- Is the local participant muted?
- Who are the participants?
- Which speaker is talking?
- What should happen if the network connection drops?
This is where building a meeting recorder becomes substantially more complicated than simply gaining access to system audio. While native OS APIs don't offer meeting context, a Desktop Recording SDK provides meeting events and participant information.
Why building from scratch is usually the wrong option
Developers will sometimes try to use native OS APIs to build meeting recorders from scratch. However, most of these APIs can't capture both application audio and microphone, and none of them account for all of the edge cases related to meeting recording, like echo cancellation, audio synchronization, and more.
Reliable, high-quality audio capture is essential for a production-ready meeting recorder. Using a native API to build an audio capture pipeline means accounting for countless issues before being ready for production.
| Solution | OS | App/process audio | Whole-system audio | Microphone | Fit for a meeting recorder |
|---|---|---|---|---|---|
| Desktop Recording SDK | macOS + Windows | ✅ | ✅ | ✅ | Best fit — built specifically for meeting recording and handles meeting detection, audio sync, echo cancellation, metadata, and transcription |
| Core Audio Taps | macOS 14.2+ | ✅ | ✅ | ❌ | Useful for capturing outgoing audio from selected processes, but microphone capture and the rest of the meeting pipeline need to be built separately |
| ScreenCaptureKit | macOS | ✅ | ✅ | ✅* | Good building block, but you still need to build meeting detection, synchronization, fallbacks, and other recording infrastructure |
| WASAPI Loopback | Windows | ✅ | ✅ | ❌ | Can exclude specific audio processes manually, microphone capture needs to be built separately |
| AVFoundation | macOS | ❌ | ❌ | ✅ | Useful for microphone capture, but not sufficient by itself for recording meeting output audio |
Desktop Recording SDK: A better way to capture meeting audio
Instead of building separate pipelines for system audio, app audio, microphone capture, synchronization, echo cancellation, meeting detection, and platform-specific edge cases, you can integrate a Desktop Recording SDK designed specifically for meetings.
The Desktop Recording SDK supports major meeting platforms like Zoom, Google Meet, and Microsoft Teams as well as in-person meetings, across both macOS and Windows.
The Desktop Recording SDK handles:
- Meeting audio and microphone capture
- Automatic meeting detection
- Echo cancellation
- Audio synchronization
- Mute-state detection
- Speaker names and participant metadata
- Audio and video recording
- Real-time and post-call transcription
- Network and device edge cases
For a desktop meeting recorder, the goal is not simply to capture computer audio; it is to isolate the audio that belongs to the meeting and preserve it together with the microphone and meeting context. System-wide capture can mix unrelated applications into the recording, while native OS APIs still leave the recorder responsible for meeting detection, synchronization, echo cancellation, mute state, device handling, and transcription.
A Desktop Recording SDK provides isolated meeting audio, microphone, and meeting context, as well as support for echo cancellation and other audio edge cases. Using the SDK lets you build a production-ready meeting recorder without maintaining a complex audio pipeline from scratch.