Re: Question: What is the impact of changing .cpp AudioUnitEffect source to .mm
Re: Question: What is the impact of changing .cpp AudioUnitEffect source to .mm
- Subject: Re: Question: What is the impact of changing .cpp AudioUnitEffect source to .mm
- From: Iain Houston <email@hidden>
- Date: Mon, 21 Jun 2010 10:43:04 +0100
Thanks Kyle.
On 21 Jun 2010, at 07:11, Kyle Sluder wrote:
> On Sun, Jun 20, 2010 at 10:02 PM, Iain Houston <email@hidden> wrote:
>> Kyle - how can we evidence this?
>
> Detailed technical analysis, including precisely why and when
> objc_msgSend will block, has already been posted to this thread.
Excellent. Am searching archives again. Quite a lot of stuff since 2006;
quite a lot of qualification.
(But search.lists.apple is failing regularly!)
>
>> objc_msgSend is supposed not to block nonatomic methods.
>
> ... the lock we're talking about blocking on happens at
> low-level method dispatch, so nothing about properties, which are a
> concept built on top of regular methods, could possibly avoid this
> lock.
OK. I assumed every cached selector not specifically accessing properties atomically would
not be impacted by a lock.
Again, will search archives to pick up earlier posts on this thread
(when the lists become available again).
>
>> The answer is relevant here. e.g. to anyone attempting to distinguish what aspects of the program
>> structure of the aurioTouch sample are historical and what's currently still essential technically
>> to ensure no hiccups in obj-c deployment of remote io unit.
>
> What does "obj-c deployment of remote io unit" mean?
What I mean is making an obj-c class that hides all of the low-level detail in setting up and
maintaining efficient use of remote io unit buffers - hiding those details which are not directly
relevant to users of that class.
As usual - deciding the level of abstraction at which convenience impacts performance motivates
these questions, seeking the required understanding.
I appreciate your insight. Iain.
_______________________________________________
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