Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Core Audio taking 3 minutes to open audio device #10902

Open
3 of 15 tasks
miketoon opened this issue Nov 5, 2024 · 16 comments
Open
3 of 15 tasks

Core Audio taking 3 minutes to open audio device #10902

miketoon opened this issue Nov 5, 2024 · 16 comments

Comments

@miketoon
Copy link

miketoon commented Nov 5, 2024

Description

When starting an audio device with CoreAudio it takes 3 minutes to return when calling:

AudioDeviceStart(   AudioObjectID                   inDevice,
                    AudioDeviceIOProcID __nullable  inProcID)                                                   __OSX_AVAILABLE_STARTING(__MAC_10_0, __IPHONE_2_0);

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

  • Azure DevOps
  • GitHub Actions - Standard Runners
  • GitHub Actions - Larger Runners

Runner images affected

  • Ubuntu 20.04
  • Ubuntu 22.04
  • Ubuntu 24.04
  • macOS 12
  • macOS 13
  • macOS 13 Arm64
  • macOS 14
  • macOS 14 Arm64
  • macOS 15
  • macOS 15 Arm64
  • Windows Server 2019
  • Windows Server 2022

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

AudioDeviceStart(   AudioObjectID                   inDevice,
                    AudioDeviceIOProcID __nullable  inProcID)                                                   __OSX_AVAILABLE_STARTING(__MAC_10_0, __IPHONE_2_0);
@susmitamane
Copy link
Contributor

Hi @miketoon We will look into the issue and keep you posted with updates.

@NorseGaud
Copy link

@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?

@miketoon
Copy link
Author

@NorseGaud
Please see example app in this zip:
CoreAudioTest.zip

@NorseGaud
Copy link

NorseGaud commented Nov 19, 2024

Here is what I'm seeing on the first run.

Screenshot 2024-11-19 at 8 12 37 AM

Second run, without clicking "Allow", sits for a long time and then finally fails at:

Screenshot 2024-11-19 at 8 16 29 AM

Once I allow the Microphone, I see things work fast for the core audio logs:

Screenshot 2024-11-19 at 8 18 00 AM

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.

@miketoon
Copy link
Author

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.

@NorseGaud
Copy link

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.

@miketoon
Copy link
Author

We are building our binary using XCode
Our tests are ran from a Rake script which calls Open3.popen2e(<ARGS>) to run the binary.

@NorseGaud
Copy link

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?

@miketoon
Copy link
Author

miketoon commented Nov 20, 2024

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)

@miketoon
Copy link
Author

@NorseGaud any updates from the GitHub team? Or suggestions to how the required permissions can be given for our binary?

@miketoon
Copy link
Author

miketoon commented Dec 3, 2024

@NorseGaud any update on this?

@NorseGaud
Copy link

Hey @miketoon , I actually don't work for Github, I was just helping out. You'll need to wait for their team to get back to you. I've let them know what I recommend to test and fix this.

@aartis17
Copy link
Contributor

aartis17 commented Dec 9, 2024

Hi @miketoon ,
Thank you for your patience. I am currently investigating the issue and it is in progress. Please allow us some more time to delve deeper. So far, I have reproduced the steps locally using Xcode and imported the files you shared, but I am not receiving any prompts for microphone permissions. Please see below snip. Will come back with some updates later. Thank you.

Screenshot 2024-11-27 at 1 02 51 PM

@miketoon
Copy link
Author

@aartis17 Is this running on the runner image? I don't get the prompt on my dev machine running locally.
Have you made any further progress?

@aartis17
Copy link
Contributor

@miketoon No, It was from Xcode tool which was running on my local machine. We have investigated the issue, we couldn't able to reproduce it, as we cannot see any Yaml files there in zip file, can you please share the path if the files are present. Also, could you please share complete repro steps, Github workflow (.yaml files) and please share public Github repository link if any. Thanks.

@sanket492
Copy link

I am also facing some issue in playing audio on agent with macos-14 image #11251

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants