Re: AudioUnitRender() thread safe?

[Benjamin Federer]

> 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.

That is interesting. I’ll try to find the discussion.

> 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.

I don’t know what you mean by advanced audio app. For my current use case I am 
satisfied with AUGraph in terms of API and functionality. Documentation is 
sparse as always but sufficient enough. I even dare to say that it is the Core 
Audio API that caused the least of my confusions. It might make sense for TAAE 
as a wrapper to omit another wrapper layer, of course.
 ___
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

Re: AudioUnitRender() thread safe?

[Hovik Melikyan]

> 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  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 :
>
> 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  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 :
>
> 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 

Re: AudioUnitRender() thread safe?

[Benjamin Federer]

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 :
> 
> 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  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 :
>>> 
>>> 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/archive%40mail-archive.com

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

Re: AudioUnitRender() thread safe?

[Hovik Melikyan]

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  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 :
>>
>> 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/archive%40mail-archive.com

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

Re: AudioUnitRender() thread safe?

[Benjamin Federer]

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 :
> 
> 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/archive%40mail-archive.com

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

AudioUnitRender() thread safe?

[Benjamin Federer]

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/archive%40mail-archive.com

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