Support loopback recording on macOS #1003

SuperKenVery · 2025-08-16T13:17:40Z

This pr adds support for recording system output audio on macOS.

For usage example, please see src/host/coreaudio/macos/mod.rs test::test_record_output.

To test this, use cargo run --example record_wav --device default-output

Testing requirements:

You're on macOS 14.2 or later.
The app has permission for recording system audio. Note the "app" means the app that starts cargo run --example, e.g. VSCode or Zed.
Don't build with nix. It comes with an old macOS SDK and lacks required symbols.

Closes #876

SuperKenVery · 2025-08-16T13:18:20Z

This pr might seem a little bit messy, but most of the new code should be at src/host/coreaudio/macos/loopback.rs.

I also extracted some code frommod.rs to device.rs, and added some tests in mod.rs.

For Cargo.toml, the main change was adding some features in objc2-xxx and/or add new objc2-xxx dependencies. However, the file was automatically formatted by Zed so it looks like there're lots of changes. But formatting it is anyway a good thing, so I didn't bother reverting that.

SuperKenVery · 2025-08-16T14:11:19Z

It seems that, in the CI, test_record_output test isn't properly finishing. Not sure why, it runes fine on my machine...

Well, CI is on macOS 14.7 while I'm on 15.5. Can anyone on macOS 14 try this?

wgibbs-rs · 2025-08-16T19:03:03Z

There are some features not enabled by default. Given the kind of errors produced, I doubt this is a system-specific problem. Make sure you run the proper build commands, run unit tests, and try an example (like "beep"). To properly test this on your system, try using the following commands:

cargo test --all --no-default-features --verbose
cargo test --all --all-features --verbose

What could have changed that impacted wasm? I see the error around this is a time-out issue, so maybe try fixing MacOS and see if that resolves the wasm issue.

SuperKenVery · 2025-08-17T02:26:11Z

@wgibbs-rs Thanks for your suggestions!

Both of the following runs flawlessly on my machine:

cargo test --all --no-default-features --verbose
cargo test --all --all-features --verbose

The wasm error is probably a network issue, it didn't even get to the point to run my code. It failed at "install stable".

roderickvd · 2025-08-18T10:12:32Z

Re-ran the failed tests and they’re OK now. Edit: no you’re right, the macOS test doesn’t finish. I only have an up to date macOS too.

Thanks for your contribution! This seems like a worthwhile feature to have. I am away now and should be able to look more into it in a few days. I’ll start by triggering a Copilot review and see what it comes up with.

Copilot

Pull Request Overview

This PR adds support for loopback recording (recording system audio output) on macOS by implementing aggregate devices with taps. This enables applications to capture audio that is being played through the system's output devices.

Key changes include:

Added loopback recording capability using macOS Core Audio APIs
Restructured the device implementation to support both regular and loopback devices
Enhanced the record_wav example to demonstrate the new functionality

Reviewed Changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/host/coreaudio/macos/mod.rs	Restructured module to extract device implementation and add loopback support
src/host/coreaudio/macos/loopback.rs	New module implementing loopback device creation using aggregate devices and taps
src/host/coreaudio/macos/device.rs	Extracted device implementation with enhanced input stream building for loopback support
examples/record_wav.rs	Enhanced example to support recording from default output device with configurable duration
Cargo.toml	Added required Core Foundation and Foundation dependencies for loopback functionality

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

src/host/coreaudio/macos/loopback.rs

src/host/coreaudio/macos/device.rs

src/host/coreaudio/macos/loopback.rs

roderickvd · 2025-08-26T07:26:34Z

Any ideas how we could get it to work on macOS 14?

SuperKenVery · 2025-08-26T07:35:42Z

I think it might not be very difficult, the only problem is I don't have a macOS 14 machine.

When I get time, I could probably try to debug this in a VM.

roderickvd · 2025-08-30T13:14:56Z

Maybe it's because the CI is asking the (non-existent) user whether microphone access is allowed? Maybe have it time out?

SuperKenVery · 2025-08-31T03:21:09Z

the CI is asking the (non-existent) user whether microphone access is allowed

I think that might be the case. But why does recording test pass? It should also ask for microphone access...

SuperKenVery · 2025-08-31T10:18:50Z

Ok. I just fired up a macOS 14 VM.

It does ask for microphone permission. But after granting the permission, it does ran without problems. So, not sure what happened on CI 🤔

roderickvd · 2025-08-31T15:23:58Z

I'm no expert but maybe the problem is that loopback requires different permissions: screen capture, instead of microphone for the recording test.

I'd be OK with skipping such tests conditionally on the CI:

  #[test]
  fn test_foo() {
      if std::env::var("CI").is_ok() {
          println!("Skipping test_foo in CI environment due to permissions");
          return;
      }
      // ...
  }

simlay · 2025-08-31T20:46:29Z

Huh. I'm getting some odd behavior with the example. I've spent probably 20+ minutes trying to narrow it down but I'm more confused than I was initially. I'm on macOS 15.6.1, I've swapped between xcode 26 beta 6 and xcode 16.4 via xcode-select --switch and back. At first I thought it wasn't working as expected because my sample audio was a shakira youtube video in firefox (not trying to copy, just lazy).

I had it working in a non famous youtube music video and when I play local media. I'm not a huge audio person but the audio quality sounded like "It was under water". I wanted to provide the input recorded audio and the output from the loopback but somehow in the last 15 minutes something changed and now I don't hear anything when I play recorded.wav. I wish I had something more specific to be helpful.

SuperKenVery · 2025-09-01T03:55:08Z

@simlay Thanks for reporting!

About the youtube video, I think it might be related to DRM, but I'm not sure. If you could provide its URL I may find out something.

About the sound quality, I'm not sure what's happening. Something that comes to my mind:

According to this, macOS may have bugs handling outputs with a lot of channels:

        // Create a tap description for all processes without a specific output.
        // Note: I believe there is a bug in the CoreAudio Tap API. If the
        // default output device has 2 output channels this works as expected.
        // But if you have a device with 4 output channels then the volume of
        // the resulting buffer will be halved. You can extrapolate this to any
        // number of channels.

        // This bug is also present in ScreenCaptureKit if you use it on macOS
        // 14.2 or later. The bug is not present in macOS 14.1 or earlier.

        // A workaround for this issue could be to increase the volume of the
        // audio in the output by the number of channels. Or simply use the
        // other API to tap a specific output.

Make sure you are recording from "default-output" device, and not from your microphone.

About playing the wav file, well, that's really strange! Hope you would figure it out~

SuperKenVery · 2025-09-01T03:57:54Z

@roderickvd

loopback requires different permissions: screen capture

In my case (macOS 15.6.1) there are two sections in the screen capture permissions, "Screen capture and system audio" and "system audio only" (I translated from Chinese, might not be word accurate). It should require the "system audio only" permission.

However on macOS 14, the OS only asks for the microphone permission when running the tests.

I'm personally OK with skipping it on CI, but I'm curious why the microphone tests pass on CI? I didn't see any permission granting thing on the workflow file...

roderickvd · 2025-09-01T06:45:39Z

I don’t know and can only guess that it has something to do with these permissions. Fixing the CI without skipping the test would be great but if we can’t win the fight, then let’s spend our energy elsewhere.

Because of permissions. Fuck apple.

SuperKenVery · 2025-09-01T09:39:27Z

then let’s spend our energy elsewhere

Agreed. I've now disabled the check on CI and all checks have passed 😄

roderickvd

Thanks for getting the CI to pass. Couple of review comments.

roderickvd · 2025-09-04T19:53:19Z

src/host/coreaudio/macos/device.rs

+        };
+        coreaudio::Error::from_os_status(status)?;
+        let ranges: *mut AudioValueRange = ranges.as_mut_ptr() as *mut _;
+        let ranges: &'static [AudioValueRange] = unsafe { slice::from_raw_parts(ranges, n_ranges) };


Should this be &'static or just &?

This code isn't really written by me... I just moved it to another file.

But looking at the code, it seems it should be & as it's a locally-declared Vec. But maybe it didn't return this pointer so it didn't cause any problem.

Would you check?

Yes sure. Will do that will I get back to my computer~

src/host/coreaudio/macos/loopback.rs

Cargo.toml

By not checking the return status

SuperKenVery added 3 commits August 14, 2025 17:54

Add env

f0b2602

Code writing is done

2342303

It works now

adfa66f

Remove nix env

7c1bdd8

SuperKenVery mentioned this pull request Aug 16, 2025

Suppport ScreenCaptureKit loopback #876

Open

Resolve warnings

2f00572

roderickvd requested a review from Copilot August 18, 2025 10:12

roderickvd added enhancement host - coreaudio labels Aug 18, 2025

Copilot AI reviewed Aug 18, 2025

View reviewed changes

src/host/coreaudio/macos/loopback.rs Outdated Show resolved Hide resolved

src/host/coreaudio/macos/device.rs Outdated Show resolved Hide resolved

src/host/coreaudio/macos/device.rs Outdated Show resolved Hide resolved

src/host/coreaudio/macos/loopback.rs Outdated Show resolved Hide resolved

SuperKenVery added 2 commits August 18, 2025 19:13

Apply some copilot suggestions

6ce7f03

Move some logic from device.rs to loopback.rs

f3dc9e6

Skip loopback recording test on CI

5f66963

Because of permissions. Fuck apple.

roderickvd reviewed Sep 4, 2025

View reviewed changes

Prevent panic in drop

cec3438

By not checking the return status

Support loopback recording on macOS #1003

Are you sure you want to change the base?

Support loopback recording on macOS #1003

Uh oh!

Conversation

SuperKenVery commented Aug 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SuperKenVery commented Aug 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SuperKenVery commented Aug 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wgibbs-rs commented Aug 16, 2025

Uh oh!

SuperKenVery commented Aug 17, 2025

Uh oh!

roderickvd commented Aug 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

roderickvd commented Aug 26, 2025

Uh oh!

SuperKenVery commented Aug 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

roderickvd commented Aug 30, 2025

Uh oh!

SuperKenVery commented Aug 31, 2025

Uh oh!

SuperKenVery commented Aug 31, 2025

Uh oh!

roderickvd commented Aug 31, 2025

Uh oh!

simlay commented Aug 31, 2025

Uh oh!

SuperKenVery commented Sep 1, 2025

Uh oh!

SuperKenVery commented Sep 1, 2025

Uh oh!

roderickvd commented Sep 1, 2025

Uh oh!

SuperKenVery commented Sep 1, 2025

Uh oh!

roderickvd left a comment

Choose a reason for hiding this comment

Uh oh!

roderickvd Sep 4, 2025

Choose a reason for hiding this comment

Uh oh!

SuperKenVery Sep 5, 2025

Choose a reason for hiding this comment

Uh oh!

roderickvd Sep 7, 2025

Choose a reason for hiding this comment

Uh oh!

SuperKenVery Sep 7, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

SuperKenVery commented Aug 16, 2025 •

edited

Loading

SuperKenVery commented Aug 16, 2025 •

edited

Loading

SuperKenVery commented Aug 16, 2025 •

edited

Loading

roderickvd commented Aug 18, 2025 •

edited

Loading

SuperKenVery commented Aug 26, 2025 •

edited

Loading