Re: AudioUnits: Threading of property fetching and Render-proc
Re: AudioUnits: Threading of property fetching and Render-proc
- Subject: Re: AudioUnits: Threading of property fetching and Render-proc
- From: Heinrich Fink <email@hidden>
- Date: Fri, 10 Jul 2009 13:26:52 +0200
Bill,
thanks for your comments on this topic.
If there is no way to mutually exclude the render process from fetching properties could this be achieved by (ab)using parameters?
you can transfer data to and from your list by looking at some kind of lock free list of some description - then your "get" calls would only get data that is safe and not be in a problem if the render call is modifying the list in some way
I have found the following articles that I think were previously mentioned on this list:
http://www.audiomulch.com/~rossb/code/lockfree/
http://www.ddj.com/hpc-high-performance-computing/208801974
While I was just about to finish my wrapper around an single reader/single writer FIFO Ringbuffer implementation of the Port Audio project (see below), I stumbled across CAThreadSafeList.h that uses CAAtomicStack.h in the Core Audio C++ sdk. From what I could read out of the code so far, it seems this implementation is lock-free as well, thus safe to be used in my scenario.
However, I am not sure if this implementation is efficient in terms of a realtime producer/consumer paradigm. Does anyone have had experience with this implementation? Unfortunately there is very little documentation on this in the SDK.
Just fyi:
Port Audio FIFO Ringbuffer (thread safe for one writer and one reader, actual buffer data holds the client):
http://portaudio.com/trac/browser/portaudio/trunk/src/common/pa_ringbuffer.h
http://portaudio.com/trac/browser/portaudio/trunk/src/common/pa_ringbuffer.c
thanks,
h |
_______________________________________________
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