Re: scheduling a block from a render callback
Re: scheduling a block from a render callback
- Subject: Re: scheduling a block from a render callback
- From: Kyle Sluder <email@hidden>
- Date: Tue, 14 Jan 2014 10:01:30 -0800
On Jan 14, 2014, at 8:27 AM, Paul Davis <email@hidden>
wrote:
>
> The problem is lack of knowledge about how to use the API(s) that exist already, combined with programmer reluctance to use NonCamelCase APIs, combined with Apple reluctance (Doug notably excluded) to recommend using NonCamelCase APIs.
I daresay you, developer of a cross-platform audio routing library and a
DAW built atop of it, are far more familiar and comfortable with POSIX
synchronization APIs than the typical programmer using Audio Units. ;-)
Really, most Audio Units clients just want to do some funky effect to
the mic input and update the display. They don’t know and won’t learn
about pthreads, and certainly not to the depth required to understand
the implications of the newsgroup post you linked to—assuming they would
ever know it existed anyway.
The sad reality about multithreading in C is that the wrong thing often
works (or seems to work) and is far easier than doing the right thing.
Why do you think we have so many people trying to call ObjC methods or
allocate memory within their render callbacks?
>
> Besides that, your API design assumes quite a few things that are not assuredly the common case. The idea that the notification wants a particular function/handler executed is the most basic one. Good design here separates the notification from "what happens when something gets the notification".
I really don't understand what you're referring to here. My proposed API
takes a single uint32_t that names the notification being posted.
Subscribers register their handlers by associating a block to the same
integer value.
This is analogous to every notification API I’ve ever seen, from
select(2) to NSNotificationCenter.
> Consider a sort of basic case that I deal with all the time: the realtime thread notices that the disk data buffers are running low (on space or data) and would like to make sure that whoever takes care of that knows that it should get busy. In my case, the thread(s) that will care may already be busy doing disk i/o or other stuff, and the work of "fixing" the situation will be (necessarily) interleaved among their other responsibilities. With the sort of design that you're suggesting, the "handler" function is nothing more than another forwarding agent that just adds overhead to the notification process.
>
My API solves the general case: realtime thread A needs to notify other
parts of the app to do work. It is deliberately lightweight to
accommodate simple cases like the _far_ more common “update the UI”,
while accommodating more complicated scenarios like yours in a
straightforward manner.
The average iOS programmer will do the following:
@implementation MyViewController
#define DID_FUNKY_STUFF 13
- (void)setup {
AudioUnitAddNotificationHandler(
_unit,
DID_FUNKY_STUFF,
dispatch_get_main_queue(),
^{ [self.view setNeedsDisplay]; });
AudioUnitAddRenderNotify(_unit, DoFunkyStuff, NULL);
}
@end
This solves an _extremely_ common class of bugs which arise when the
developer sends -setNeedsDisplay directly from the render callback,
without requiring the developer to understand the nuances of pthreads or
multithreading in general.
As far as more complicated scenarios are concerned, I don't understand
your objection to "another forwarding agent." Trampoline functions are
extremely common when dealing with notification APIs. One germane
example is the whole async-safe signal handler technique of write(2)ing
to a self-owned pipe, in which the signal handler becomes a trampoline
function (and then uses another notification API to perform the real
work).
--Kyle Sluder
_______________________________________________
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