macOS asks for permission to use the microphone

[tsukinoko-kun]

Bevy version

0.13.2

[Optional] Relevant system information

macOS Sonoma 14.5

MacBook Pro 13" M2

What you did

When I run the game on macOS from the terinal, RustRover and the compiled binary.

What went wrong

It works but macOS asks for microphone permission.

Additional information

[mockersf]

Does this happen with Bevy examples?

[tsukinoko-kun]

I tried volumetric_fog and it happened there too.

[mockersf]

can't reproduce on my Mac

[janhohenheim]

I can remember running into this while running Foxtrot on my macOS, which surprised me. I'll check if I can reproduce this with the given example.

[janhohenheim]

I can confirm I can reproduce the bug. I thought I couldn't at first, but then realized that I already had disallowed my terminal to use the microphone, so no new popup came up. Steps to reproduce:

• compile volumetric_fog on main
• download a fresh iTerm2, because a new app doesn't have any previous security and access settings on my machine
• run the previously compiled example on iterm (ignore the path not found errors, that's because I switched branches):

results in:

My machine:

From experience, I know that at least Foxtrot asks for the same permission when setting it up as a regular graphical app without running it in the terminal.

[janhohenheim]

Update: I found a relevant thread on Discord from a year ago. Something about permissions being weird when info.plist is missing.

[bash]

I used tccutil to reset the microphone permission for the terminal app. That way the permission prompt shows up again when I run a bevy app (cargo run --example volumetric_fog on main).

By resetting the permissions before running a bevy app I can get the prompt to consistently show up.

For macOS' Terminal the command is tccutil reset Microphone com.apple.Terminal. Alternatively for WezTerm: tccutil reset Microphone com.github.wez.wezterm

[bash]

I managed to narrow this down to the function default_output_device in cpal which gets called via AudioPlugin → AudioOutput::default → OutputStream::try_default.

cpal::default_host().default_output_device();

[janhohenheim]

Marking as blocked since this seems like a cpal issue then. Unless we can pass some magic parameters.

[benfrankel]

Is there an upstream issue for this?

EDIT: Yes there is: RustAudio/cpal#901