I'm building an audio app with my own internal objects mixed with some system AU's. As I understand it, passing parameter changes via AudioUnitSetProperty() is taken care of in terms of thread synchronization. Now my own internal objects that render audio need to receive certain parameters in an efficient and thread safe manner.
Firstly, for atomic/aligned types such as Float32 or Int32 there has to be a simple mechanism and I'm wondering, e.g. which of the memory_order model should be used with these parameters. The thing with parameters like volume and mute is that in principle it is not required for changes to be immediately available for the audio thread, but it should be "soon enough", say they should take effect during the next rendering cycle. My first question is then, if I use std::atomic<> (which I admit I still don't understand very well), which memory ordering model to use? Is the relaxed model sufficient in this case? On the other hand, is acquire/release semantics too expensive for what I need? Second, in more complicated cases like passing a block of parameters to a parametric EQ, what is the best mechanism? I'm thinking of two options: one is a lock-free queue. There are some good implementations that involve malloc() but only on the producer (i.e. main) side, but not the consumer (audio), which seems like a good tradeoff for audio apps. Another option I've found is a less known algorithm called "optimistic reader" that involves a shared counter. The writer increments the counter once when it starts writing and one more time when it ends. The reader, in its turn, reads the counter, reads the data, then compares the counter with the stored value. If the values don't match it means the data block is likely inconsistent, and that it should retry. While it sounds simple and elegant, there is at least one major drawback that potentially the consumer may end up looping a lot. Also for me there is a question again what memory ordering model to use with the counter. I would appreciate if you could give me any hints or directions. Thanks! -- Hovik Melikyan _______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
