Big Sur seems to be more sensitive than Catalina to AudioServerPlugins taking too long to start and stop IO.

"Slow" in this context means anything over 50µs, and at times stop and start were occasionally exceeding 1 millisecond. The result was slipped timestamps, dropped audio & general glitchiness.

A large part of the time seems to be spent in sending a start/stop IO task to the non-realtime task thread, which creates a shadow map task which is executed on the realtime thread. The time needed to execute the task seems to be swamped by coordinating the 3 threads (driver thread -> non-realtime -> thread and back). On top of this Start/StopIO are sync, whereas the WillBeginIO/WillEndIO versions are async.

I found that making the Start/StopIO use the async versions fixed the problem in my testing.

The AudioServerPlugin documentation (the header file) isn't very clear on which callbacks are considered realtime, a conservative interpretation might include all functions with IO in their name, so I don't know how the task queue stuff fits in here, but does the above solution sound sane or are does it ring alarm bells?

Building play through into the audio server plugin is incredibly convenient... but isn't HAL access from the plugin unsupported?

From AudioServerPlugin.h:

An AudioServerPlugIn operates in a limited environment. First and foremost, an AudioServerPlugIn
may not make any calls to the client HAL API in the CoreAudio.framework. This will result in
undefined (but generally bad) behavior.

This document says "HAL" includes anything in AudioHardware.h, e.g. AudioDeviceStart: https://developer.apple.com/library/archive/documentation/MusicAudio/Conceptual/CoreAudioOverview/WhatsinCoreAudio/WhatsinCoreAudio.html So technically proxy-audio-device should expect this "generally bad, undefined" behaviour. Yet it in practice it seems to work fine. Is the only danger the occasional deadlock?

Because you're using its CFPlugInFactories UUID which is 99A15A8B-DA3C-42C3-BD5D-D035A0C2377A (see Info.plist)

The strings? I saw! I think the whole thing is fantastic! Best AudioServerPlugin I’ve seen yet.

Building play through into the audio server plugin is incredibly convenient... but isn't HAL access from the plugin unsupported?

From AudioServerPlugin.h:

An AudioServerPlugIn operates in a limited environment. First and foremost, an AudioServerPlugIn
may not make any calls to the client HAL API in the CoreAudio.framework. This will result in
undefined (but generally bad) behavior.

This document says "HAL" includes anything in AudioHardware.h, e.g. AudioDeviceStart: https://developer.apple.com/library/archive/documentation/MusicAudio/Conceptual/CoreAudioOverview/WhatsinCoreAudio/WhatsinCoreAudio.html So technically proxy-audio-device should expect this "generally bad, undefined" behaviour. Yet it in practice it seems to work fine. Is the only danger the occasional deadlock?

Could you cast the function pointer?

I'm using BGMDriver only and getting lag from BGM when included in an aggregate device.

@kyleneideck you're right, TPCircularBuffer is C. With 1 #import statement.

There's a tag but no release.

Releases seem to be needed by swift package manager...

Actually, I maybe confused - I think my problem is that I'm trying to use 4.0.4 in a Swift 4.2 SPM project.

There's a tag but no release.

Releases seem to be needed by swift package manager...