Creating an Audio Server Driver Plug-in

At a glance

Project structure

Source bundle/
├── NullAudio.c
├── Configuration/
│   └── SampleCode.xcconfig
├── NullAudio-Info.plist
└── NullAudio.xcodeproj/
    ├── .xcodesamplecode.plist
    └── project.pbxproj

Structure observations

• NullAudio.c is both the plug-in implementation and the state boundary; there is no app-defined class hierarchy.
• NullAudio-Info.plist identifies the bundle as a loadable plug-in, while the C factory exposes its driver interface.
• The sample deliberately models one fixed device, so its plug-in, box, device, stream, and control state stays at file scope.

Overall architecture

flowchart LR
    Host["Core Audio HAL"]
    Factory["NullAudio_Create factory"]
    DriverRef["Static AudioServerPlugInDriverRef"]
    Callbacks["NullAudio_* callback table"]
    State["File-scope plug-in and device state"]
    Host --> Factory
    Factory --> DriverRef
    DriverRef --> Callbacks
    Callbacks --> State
    Callbacks --> Host

Reference code

NullAudio.c:234 — static driver interface and reference

static AudioServerPlugInDriverInterface gAudioServerPlugInDriverInterface = {
    NULL,
    NullAudio_QueryInterface,
    NullAudio_AddRef,
    NullAudio_Release,
    NullAudio_Initialize,
    // ... property and I/O callbacks ...
};
static AudioServerPlugInDriverInterface* gAudioServerPlugInDriverInterfacePtr =
    &gAudioServerPlugInDriverInterface;
static AudioServerPlugInDriverRef gAudioServerPlugInDriverRef =
    &gAudioServerPlugInDriverInterfacePtr;

NullAudio.c:265 — CFPlugIn factory

void* NullAudio_Create(CFAllocatorRef inAllocator, CFUUIDRef inRequestedTypeUUID)
{
    void* theAnswer = NULL;
    if (CFEqual(inRequestedTypeUUID, kAudioServerPlugInTypeUUID)) {
        theAnswer = gAudioServerPlugInDriverRef;
    }
    return theAnswer;
}

Interpretation

The Core Audio host discovers the exported factory, receives the sample’s singleton driver reference, and invokes the functions stored in gAudioServerPlugInDriverInterface. Those static callbacks read or mutate the translation unit’s shared plug-in and device state.

Ownership and state

flowchart TD
    Module["NullAudio.c translation unit"]
    Interface["Static driver interface and reference"]
    PlugInState["gPlugIn_* and gBox_* state"]
    DeviceState["gDevice_*, gStream_*, and control state"]
    Locks["State and I/O mutexes"]
    Module --> Interface
    Module --> PlugInState
    Module --> DeviceState
    Locks -. "coordinate access" .-> PlugInState
    Locks -. "coordinate access" .-> DeviceState

Ownership evidence

NullAudio.c:126 — explicit file-scope state boundary

// This driver only ever has a single device. If multiple devices were supported,
// this state would need to be encapsulated in one or more structs.
static pthread_mutex_t gPlugIn_StateMutex = PTHREAD_MUTEX_INITIALIZER;
static UInt32 gPlugIn_RefCount = 0;
static AudioServerPlugInHostRef gPlugIn_Host = NULL;

static CFStringRef gBox_Name = NULL;
static Boolean gBox_Acquired = true;

static pthread_mutex_t gDevice_IOMutex = PTHREAD_MUTEX_INITIALIZER;
static Float64 gDevice_SampleRate = 44100.0;
static UInt64 gDevice_IOIsRunning = 0;
static Float64 gDevice_HostTicksPerFrame = 0.0;

This is module ownership rather than object ownership: static storage lives for the loaded plug-in’s lifetime, and the source explicitly notes that a multi-device driver would need per-device structs instead of these globals.

Class and protocol design

NullAudio.c:177 — exported factory and static callback declarations

void* NullAudio_Create(CFAllocatorRef inAllocator, CFUUIDRef inRequestedTypeUUID);
static HRESULT NullAudio_QueryInterface(void* inDriver, REFIID inUUID, LPVOID* outInterface);
static ULONG NullAudio_AddRef(void* inDriver);
static ULONG NullAudio_Release(void* inDriver);
static OSStatus NullAudio_Initialize(AudioServerPlugInDriverRef inDriver,
                                     AudioServerPlugInHostRef inHost);

There is no app-defined class or protocol. The procedural equivalent is the framework-defined callback-table contract plus a translation-unit-owned singleton state store.

Access control

Reference code

NullAudio.c:177 — linkage boundary

void* NullAudio_Create(CFAllocatorRef inAllocator, CFUUIDRef inRequestedTypeUUID);
static HRESULT NullAudio_QueryInterface(void* inDriver, REFIID inUUID, LPVOID* outInterface);
static OSStatus NullAudio_Initialize(AudioServerPlugInDriverRef inDriver,
                                     AudioServerPlugInHostRef inHost);

In C, static at file scope provides translation-unit privacy. The factory is deliberately non-static; the callback implementations and mutable singleton state remain internal.

Logic ownership and placement

Design patterns

Naming conventions

• Functions use the NullAudio_ prefix to namespace the factory and every Core Audio callback in C.
• File-scoped mutable state uses domain prefixes such as gPlugIn_, gBox_, gDevice_, and gStream_.
• Constants use k... names, including fixed object identifiers such as kObjectID_Device and kObjectID_Stream_Input.
• The single NullAudio.c file emphasizes the procedural contract; it is not organized as one type per file.

Architecture takeaways

• NullAudio_Create is the source-visible plug-in entry; it returns a statically initialized AudioServerPlugInDriverRef rather than constructing an object graph.
• gAudioServerPlugInDriverInterface is the architectural contract: Core Audio reaches all lifecycle, property, timing, and I/O behavior through its callback slots.
• NullAudio.c owns singleton state because the sample has one fixed device; the source explicitly recommends structs for a multi-device design.
• External linkage is limited to the factory, while callbacks and state are static implementation details.
• The design is procedural and callback-driven, not protocol-oriented in the Swift sense.

Source map

• Official Apple documentation