Apple

On Tue, Sep 16, 2014 at 3:41 PM, Charles Constant <email@hidden> wrote:

> the fact that you can't use a swift function for the render callback given the API design
> does seem indicative of the sort of message apple may want to send here ....

Swift may well be inherently inappropriate for render callbacks, but I imagine Swift's inability to create a CFunctionPointers has far-enough reaching effects that some of them wouldn't involve performance.

> I'm puzzled why you think this is possible. Last time I read about
> this, Apple's position was that realtime (i.e. low latency) audio
> still required C/C++.

Well, evidently it's because *I* hadn't read that : ) If that's their position, I'm glad I stopped trying. I'm quite sure queuing up scheduled segments, and handling menial tasks in the completion callbacks, should be okay in the *new* API though, since the WWDC examples were all Obj-C and presumably Swift performance should wind up comparable to Obj-C.

You have examples of render callbacks implemented in Objective C?

People misunderstand the issue of language choice. It isn't about the *amount* of work that needs doing. It is about invisible, unpredictable overhead that the language runtime library may incur outside your control.

This is why objective C has never been acceptable for render callbacks, and why any language that attempts to remove the "pain" of C or C++ is also likely not acceptable (though there could be an exception at some point).