On Mon, Feb 26, 2018 at 9:16 PM, Brian Armstrong < [email protected]> wrote:
> As a related question, is there any reason not to just feed the audio > thread with a ringbuffer filled on a different thread? You could manage > pointers either with try-lock or atomics. > that's exactly what you're supposed to do. and what just about every correctly implemented audio application does. except that processing needs to happen in the audio thread to minimize latency. imagine the user tweaks the parameter of a plugin. they expect to hear the result ASAP. if you pre-process the audio before it hits the audio thread, you can't ensure that. so, you disk i/o and other non-latency-dependent processing outside the audio thread, write to the buffer; audio thread reads from it, runs plugins and the rest, delivers to the "hardware" (you don't have access to the hardware with coreaudio, but the concept is the same). you don't need locks on a single-reader/single-writer circular buffer. you do need to ensure correct memory ordering.
_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
