std::atomic and lock free algorithms with Core Audio
std::atomic and lock free algorithms with Core Audio
- Subject: std::atomic and lock free algorithms with Core Audio
- From: Hovik Melikyan <email@hidden>
- Date: Sat, 10 Sep 2016 23:38:23 +0100
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden