Open miketoon opened 3 weeks ago
Hi @miketoon We will look into the issue and keep you posted with updates.
@miketoon , I can't seem to reproduce this. I tried using an application that utilizes AudioDeviceStart
. Can you provide me with a way to reproduce this?
@NorseGaud Please see example app in this zip: CoreAudioTest.zip
Here is what I'm seeing on the first run.
Second run, without clicking "Allow", sits for a long time and then finally fails at:
Once I allow the Microphone, I see things work fast for the core audio logs:
I am not using a GitHub runner Mac though, so this is a pure VM. @susmitamane , check with the team and see if the Microphone permissions are the issue by manually testing this in Github's environment/VMs.
The timing matches up with what I am seeing when on a runner. This is strange because we are attempting to start the device without any audio input so I am not sure why access is even being requested.
It may be a consequence of Apple's design :( I think there is a way around this. Can you clarify what binaries/commands you run to build/test? There is a way to preapprove certain binaries for certain permissions in the Github runner images but the team needs to know exactly what you're running that does the build.
We are building our binary using XCode
Our tests are ran from a Rake script which calls Open3.popen2e(<ARGS>)
to run the binary.
Sorry, so the issue isn't with building but running your binary? Let's see what the Github team recommends here. It could be the permissions for rake weren't added to the VM when it was created, so try running the binary without it and see if it's still a problem.
Is your binary and rake script something you could share privately with us so we can test again? Maybe you can create a tiny version of the script with just the necessities?
The same issue happens when running the binary directly on the runner. I think this is what you've already seen when running the example app and the popup appears.
Output running directly on runner:
Generating script.
Script contents:
./Builds/MacOSX/build/Release/FIngerprintTests
========================== Starting Command Output ===========================
/bin/bash --noprofile --norc /Users/runner/work/_temp/07c3b6fc-9442-43e4-a37f-2e88fb8d5ca8.sh
Tracktion DM: init 0 seconds
Tracktion DM: scan end 0 seconds
Tracktion DM: pick end 0 seconds
Tracktion DM: init default start 0 seconds
Tracktion DM: init default AudioDeviceSetup end 0 seconds
Tracktion DM: Insert default device names 0 seconds
Tracktion DM: type CoreAudio 0 seconds
Tracktion DM: output to test Null Audio Device 0 seconds
Tracktion DM: insertDefaultDeviceNames end 0 seconds
Tracktion DM: setAudioDeviceSetup start 0 seconds
Tracktion DM: stop Device start 0 seconds
Tracktion DM: setAudioDeviceSetup end 0 seconds
Tracktion DM: type CoreAudio 0 seconds
Tracktion DM: needsNewDevice start 0 seconds
Tracktion DM: deleteCurrentDevice start 0 seconds
Tracktion DM: deleteCurrentDevice end 0 seconds
Tracktion DM: type CoreAudio 0 seconds
Tracktion DM: updateSetupChannels start 0 seconds
Tracktion DM: updateSetupChannels end 0 seconds
Tracktion DM: currentAudioDevice->open start 0 seconds
Tracktion DM: 0 : 2 0 seconds
Tracktion DM: currentAudioDevice->open end 0 seconds
Tracktion DM: currentAudioDevice->start start 0 seconds
Tracktion CA: pre lock 0 seconds
Tracktion CA: post lock 0 seconds
Tracktion DM: currentAudioDevice->start end 180 seconds
Tracktion DM: 180 seconds
Tracktion DM: setAudioDeviceSetup end 180 seconds
Tracktion DM: init default end 180 seconds
Finishing: Run FIngerprintTests (Mac)
@NorseGaud any updates from the GitHub team? Or suggestions to how the required permissions can be given for our binary?
Description
When starting an audio device with CoreAudio it takes 3 minutes to return when calling:
We are trying to upgrade from macosx12 but are running into this issue with our tests where we need to repeatedly start an audio device. This is causing a massive delay to the tests which is unworkable.
Platforms affected
Runner images affected
Image version and build link
macos13: Current image version: '20241023.237' macos 15: Current image version: '20241022.244'
Is it regression?
Yes macosx12
Expected behavior
Audio device is started in a few seconds or less
Actual behavior
Audio device doesn't start for 3 minutes hanging the application
Repro steps
call to