Post not yet marked as solved
That is, will my render callback ever be called after AudioOutputUnitStop() returns?In other words will it be safe to free resources used by the render callback or do I need to add realtime safe communication between the stopping thread and the callback thread?This question is intended for both macOS HAL Output and iOS Remote IO output units.
Post not yet marked as solved
In an installer-free, non MAS mac app, I need to let the user do the equivalent ofsudo (cp MyAudioDriver.driver /Library/Audio/Plug-Ins/HAL/ && killall coreaudiod)so they request the installation of the optional component, see the standard “[App X] wants to make changes, enter a password to continue” and the above happens with elevated privileges.After looking at the sample code `SMJobBless`, `BetterAuthorizationSample` and `EvenBetterAuthorizationSample` (we don’t talk about plain `AuthorizationSample` any more), the picture that I’m getting is that the solution is a mixture of 1. use SMJobBless to install privileged helper app managed by launchd (this - hopefully - can do the one-liner above) 2. code signing & (mutual?) whitelist to establish trust between app and helper 3. XPC for communication between helper and app (hi, this is the app, please install the thing)This seems so complicated, is this really the way to do what I want in a non-deprecated fashion? The client justifiably points out that requesting elevated permissions for Accessibility scripting is very easy, but there’s a dedicated API for that.I got the SMJobBless sample code working, and confusingly, its security dialog says “[App X] wants to install a helper app, enter password” which is not the message I want to give, so hopefully there’s some plist customisation somewhere where I can say “[App X] wants to install an audio component”.Am I on the right path?I have many doubts and questionsXPC to a privileged app is apparently not supported (mentioned here: http://atnan.com/blog/2012/02/29/modern-privileged-helper-tools-using-smjobbless-plus-xpc/)can I shell out to the one liner script? it's codesigned...aren't helper apps supposed to be long running?every other app seems to have the "[App X] wants to make changes" dialog. Does that mean they're using the deprecated AuthorizationExecuteWithPrivileges()? or are they asking AppleScript to run a shell script with elevated privileges?the calling app is not a bundle, it's just a binary/CLI tool, that acts as a plug-in for an electron .app package/bundle. can the CLI tool communicate with the helper?I'm no security expert, but having a helper app/server running as root & performing commands (in this case file copies to directories owned by root) on behalf of my app seems kinda... insecure.
Post not yet marked as solved
At some point (Swift 4?) I found it became possible to use dot notation for CoreMedia object properties, so code like thislet asbd = CMAudioFormatDescriptionGetStreamBasicDescription(CMSampleBufferGetFormatDescription(sampleBuffer)!)!.pointeebecamelet asbd = sampleBuffer.formatDescription!.audioStreamBasicDescription!.pointeeThis no longer compiles (Xcode10.1/Swift 4.2). I'm pretty sure I didn't dream this, does anyone know what happened?
Post not yet marked as solved
I've been working on a watchOS extension that uses background refreshes and background downloads to periodically update a complication. (Xcode 10.0/10.13.6, series zero 🙂 watch/watchOS 4.3.2, iPhoneX/12.0).Everything works really well, but only while the paired iPhone is charging. When the phone is not charging, the server sees no http request and no WKURLSessionRefreshBackgroundTask is passed to handleBackgroundTasks:.Can anyone think of an explanation for this? I'm at a loss.p.s. I recently found this forum post about NSURLSession's Resume Rate Limiter https://forums.developer.apple.com/message/42352It refers to iOS, but it's not hard to imagine how it might apply to watchOS. This post explains many of the strange phenomena seen when working with background downloads on watchOS and should immediately be promoted to full documentation and reproduced verbatim on every page of the NSURLSession and WatchKit docs, and also referenced from timeoutIntervalForResource (getting exponentially rate limited for network timeouts while the background refresh mechanism thinks you're ok is extremely surprising). I can't see however how the RRL could explain my above problem.p.p.s I've been away a while - what happened to the content on the old https://devforums.apple.com ? Is it gone forever?
rhythmicfistman.