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: Brian Armstrong <email@hidden>
- Date: Tue, 27 Feb 2018 03:46:59 +0000
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@hidden>
wrote:
> 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