Re: Any system calls OK to use in audio thread?
Re: Any system calls OK to use in audio thread?
- Subject: Re: Any system calls OK to use in audio thread?
- From: Paul Davis <email@hidden>
- Date: Mon, 26 Feb 2018 22:35:58 -0500
On Mon, Feb 26, 2018 at 9:16 PM, Brian Armstrong <
email@hidden> 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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden