Re: Moving data from audio thread and the other way...
Re: Moving data from audio thread and the other way...
- Subject: Re: Moving data from audio thread and the other way...
- From: Jean-Daniel Dupas <email@hidden>
- Date: Tue, 01 Nov 2011 17:06:13 +0100
I think the CARingBuffer from the core audio SDK provide such algorithm (in /Developer/Extras/CoreAudio/PublicUtility ).
Le 1 nov. 2011 à 16:31, Albin Stigö a écrit :
> Thanks for the reply!
>
> I was kind of suspecting this but wasn't able to find any examples...
> most academic papers are littered with CAS operations.
>
> Do you know of any example code?
>
> Cheers,
> Albin
>
> On Tue, Nov 1, 2011 at 4:03 PM, Jean-Daniel Dupas
> <email@hidden> wrote:
>>
>> Le 1 nov. 2011 à 13:32, Albin Stigö a écrit :
>>
>>> Hi,
>>>
>>> I know this has been discussed before at great length but looking
>>> through the archives I can't seem to find a comprehensive answer (or
>>> documentation). I've been googling and reading blogs... But I would
>>> like to review the options.
>>>
>>> I far as I know these are my options signaling from the render
>>> callback to, let's say, a thread that then triggers updates on the
>>> gui.
>>>
>>> 1. pthread_cond_signal()
>>> I understand this involves a mutex? Can't that block?
>>>
>>> 2. mach_msg()
>>> Is this ok on iphone/app store?
>>>
>>> 3. Non-blocking single producer/consumer fifo.
>>> Is this only possible using OSAtomic?
>>
>> FWIW, a single read, single writer ring buffer (FIFO) doesn't require atomic at all. It may require a barrier to guarantee memory ordering though.
>>
>> -- Jean-Daniel
>>
>>
>>
>>
>>
-- Jean-Daniel
_______________________________________________
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