Deferred audio configuration notifications¶
ProcessingHost adds audio-port, latency and tail extensions to parameter-aware
handlers. Prepare a shared parameter mailbox, a main parameter mailbox and an
AudioConfigurationRequests mailbox for each instance. Construct
ProcessingMainRequests from main parameter/audio mailbox clones for the main
factory; pass an audio mailbox clone to activation's audio-handler factory. Keep
consumer clones outside callbacks for subsequent drains. Core request service
works with either handler type.
AudioConfigurationRequests::take() coalesces port rescan flags, latency changes
and tail changes into one atomic snapshot. defer() republishes unserved kinds.
Native main-thread port/latency and audio-thread tail callbacks only publish;
there is no plugin reentry, allocation, lock or automatic lifecycle transition.
The host advertises all defined port rescan flags. Non-name changes require
consumer deactivation; this framework's full snapshot API requires deactivation
even for names. Re-query latency after activation and tail on its audio owner.
Consumers must rebuild/retire prepared routes when configuration/timing changes.
The offline example now uses these combined handlers, reports initial/activation/ post-render changes, queries latency after activation and tail before stopping on the audio worker. It does not restart or rewire itself. Linked fixtures call the actual advertised extensions on their main/activation/audio paths; tests check coalescing, deactivation flags, deferred preservation, unknown flag masking and 10,000 prepared zero-heap workloads. See decision 0064.