Hi Hovik,

thanks for commenting. I’ll try and elaborate on my thinking.

I am fairly certain I am using the AUGraph correctly. I base this assumption on 
the point that pulling audio the way I described works fine and also on my 
reading of the Core Audio documentation (where available). There’s also a very 
informative post on that topic by Bill Stewart: 
<http://lists.apple.com/archives/coreaudio-api/2009/Sep/msg00112.html>. The 
outlined point (2) in that post is basically what I am currently doing. (And 
upon re-reading it I guess I should take a look into AUBase::DoRender, wherever 
I might find that.)

To my understanding the AUGraph API internally just calls the Audio Unit API, 
i.e. AudioUnitRender() to pull audio samples and a bunch of other functions to 
create/destroy, de/initialize and dis/connect audio units – but in a thread 
safe way. Therefore, of course, adding and removing nodes is completely thread 
safe, as long as you only use AUGraph API on any other thread at the same time.

Now, if you call both, the AUGraph and the AudioUnit API, on the same audio 
unit but on different threads (think render thread and service thread), I 
assume any thread safety would fall back on the AudioUnit API. Which obviously 
does not bother with it, as you wrote. So, I guess my question would be, if it 
is true that changing parameters of an audio unit is safe, is there also some 
AudioUnit-API-inherent mechanism in place that waits for an audio unit to 
finish rendering before it gets disconnected from the signal chain, 
deinitialized and destroyed? If changing audio unit parameters simply relies on 
atomically setting some floats and picking them up at the beginning of the next 
render cycle, I guess the answer is still no.


> Am 20.09.2016 um 14:45 schrieb Hovik Melikyan <hovik.melik...@gmail.com>:
> Hi Benjamin,
> I know very little about the AUGraph as I never use it (almost always
> just AU's directly), but here are a few things to consider:
> AudioUnitRender() is not thread safe, since it probably assumes it can
> only be called on the audio thread and therefore it shouldn't bother
> with thread safety in general. At the same time changing
> parameters/attributes of an AU *is* safe, i.e. the AU will pick up the
> changes in a safe manner some time during one of the next rendering
> cycles.
> I have a suspicion though that you should not be calling
> AudioUnitRender() if you have a graph. The whole point of the graph is
> that it will handle the rendering chain for you once you call
> AUGraphStart(). Which means you may be using your graph incorrectly,
> or you might not need it at all.
> Finally, modifying the graph (adding/removing nodes) while playing
> audio is safe according to the documentation.
> Hope this helps a little,
> --
> Hovik Melikyan
> On 20 September 2016 at 13:28, Benjamin Federer <benja...@boinx.com> wrote:
>> Hello again,
>> since no-one commented on this I dare to interpret this as a) no-one knows 
>> or b) it is simply too obvious that the AUGraph API is the only thread-safe 
>> API dealing with audio units. Following either case I will treat 
>> AudioUnitRender() as unsafe.
>> Benjamin
>>> Am 15.09.2016 um 13:24 schrieb Benjamin Federer <benja...@boinx.com>:
>>> Hello everyone,
>>> I manage a couple of audio units in an AUGraph but pull the graph by 
>>> calling AudioUnitRender() on the head node’s audio unit. Am I correct in 
>>> assuming that calling AudioUnitRender() on any node’s audio unit is not 
>>> thread safe if AUGraph API is being called on the same node, like 
>>> AUGraphRemoveNode()?
>>> In case I am wrong, (how) is the AUGraph aware of any AudioUnitRender() 
>>> calls made to its nodes? Or is the audio unit taking locks internally?
>>> Thanks,
>>> Benjamin
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Coreaudio-api mailing list      (Coreaudio-api@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/coreaudio-api/hovik.melikyan%40gmail.com
>> This email sent to hovik.melik...@gmail.com

Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list      (Coreaudio-api@lists.apple.com)
Help/Unsubscribe/Update your Subscription:

This email sent to arch...@mail-archive.com

Reply via email to