Apple

I've come across a few references that suggest that locking a mutex in a render callback is a bad thing, so I'm looking for a better way to do things.

Right now I have a struct that manages playback state:

class Source

{

pthread_mutex_t mMutex;

bool mActive; // Indicates if the render callback should copy data out of mpBuffer

bool mLooping;

UInt32 mPhase; // render callback should being copying from mpBuffer[mPhase]

MxAudioBuffer const * mpBuffer;

[....] // Snipped methods

};

To begin playback of a source's buffer, I lock the source's mutex, set each of the members appropriately, and then unlock the mutex. My render callback locks the same source's mutex, copies data out of the provided buffer (accounting for the active and looping flags), and then unlocks the mutex. Thus far I've had no problems - the render callback never has to wait long to acquire the lock - but from what I've read I'm lead to believe I shouldn't be doing this anyway. I've considered pushing source information into a ring buffer instead, which would also allow me to atomically change playback information.

Could anyone suggest a good way of managing this?

Thanks!

Andrew.