> 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

I am pretty sure there is. According to one discussion on this list,
for example AudioOutputUnitStop() waits until a rendering cycle ends
in case it's called from outside of the audio thread. Which means
CoreAudio has proper synchronization mechanisms in place.

To my previous point on AUGraph and its usage: one situation when
you'd need to call AudioUnitRender() would be if you have a custom
AudioUnit that should call another one. But other than that, I don't
think you should be calling this method for a AUGraph-managed node.

In my opinion the benefits of having an AUGraph in advanced audio apps
are minimal. Even TAAE has switched to pure non-AUGraph architecture
in its 2.0 rewrite. You have to get synchronization right of course,
but at least you will not be dealing with a poorly documented black
box.


--
Hovik Melikyan


On 20 September 2016 at 19:54, Benjamin Federer <benja...@boinx.com> wrote:
> 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.
>
> Benjamin
>
>
> 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:
> 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:
https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com

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

Reply via email to