Thanks, that makes sense. Even in the example you suggested, couldn't the producer invalidate/rewrite the samples in the ring on parameter change? If the consumer reads front to back, and producer writes back to front, then the change will occur at some indeterminate point in the stream but will be applied consistently after that. Assuming correct memory fences anyway, I think.
Brian On Mon, Feb 26, 2018 at 7:36 PM Paul Davis <[email protected]> wrote: > 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]
