5 ms·
> Don’t use Objective-C/Swift on the audio thread. His argumentation is that Objective-C uses locks internally. But isn't it possible that those locks (as opp
by vemv 7y ago
> Don’t use Objective-C/Swift on the audio thread.
His argumentation is that Objective-C uses locks internally.
But isn't it possible that those locks (as opposed to application-level locks) cause just negligible pauses, because there's no contention on them?
I guess those internal locks exist to make ObjC's runtime dynamism feasible. One would expect the typical application to not leverage that dynamism (how many apps continously redefine methods under normal operation?).
- deleted 7y ago[deleted]
- jstsch 7y agoYou can use Objective C on the audio thread just fine in practice. Just don’t call out.
- adamnemecek 7y agoNo, you really can't. Show me a single audio app that uses objc in the render block.
- lfnoise 7y agoAgreed. You really must not. No sane developer would do it. Unfortunately, there are some insane developers.
- iainmerrick 7y agoIf there’s no contention, why do you think they’re there?
- deleted 7y ago[deleted]
- vemv 7y agoThey could be there as a guardrail for a worst-case scenario, without them being particularly needed for the average use case.
- Gibbon1 7y agoThe problem with locks on a non real time os is that the OS may decide to interrupt your thread while it's holding the lock. No matter how short that is. I do embedded I've had similar things happen when the 'lock' is held for just a few instructions. Tip: If you suspect crap like this, adding spin delays will make it happen often enough to debug.
- proverbialbunny 7y agoBy any chance do you have any references or information on how to do this (adding a spin delay)? It sounds interesting. -thanks :)
- Gibbon1 7y agoIn C it's very simple volatile int cnt = 0x1000; while(cnt--) ;
- hoseja 7y agoI've grown so paranoid of optimizing compilers this wouldn't even cross my mind. But it is correct, right?
- AlbertoGP 7y agoNot OP, but the “volatile” qualifier should prevent the compiler from optimizing it out.
- Gibbon1 7y agoYeah should. Multicore super scalar processors make me nervous about my assumptions. I wouldn't put it past one of them to realize that the result is unused and nop it. It's always good to check.
- vemv 7y agoI see now, thanks!
- suraj 7y agoIt is possible to use Swift on audio thread. You have to be careful not to use any reference counted (i.e. class) objects. If you do need to perform allocations (e.g. creating CMSampleBuffer instances), use a custom allocator.
- lfnoise 7y agoI had someone on the Swift compiler team tell me unequivocally that they make no real time guarantees. Unless you can point to somewhere in the language documentation that the runtime is guaranteed not to ever do X, then I would not assume that you could. (me: former Apple CoreAudio engineer)