6 ms·
That's not my takeaway from the article. It's not saying don't use "slow scripting languages", it's saying avoid language features that are not safe for real-ti
by davedx 10y ago
That's not my takeaway from the article. It's not saying don't use "slow scripting languages", it's saying avoid language features that are not safe for real-time programming and give the audio thread enough time to do its thing.
In my experience, writing everything in C/C++ has its own host of problems. What's worse, a GC stutter or a segfault? :)
- friendzis 10y agoI will take segfault over GC stutter any time of the day, because I can at least debug and fix it. GC is not really predictable
- wrl 10y agoWriting everything in C/C++ has its own host of problems, but it's roughly the name of the game in anything realtime. It's easy enough to think about writing one effect or synth in a slower language, but keep in mind that modern digital audio workstation software is expected to run up to hundreds of plug-ins to produce one block of audio, and that's just not possible without being directly on top of the metal. Even vanilla C/C++ often isn't enough; generally, there's a necessity to drop down into assembler or at the very least use SSE intrinsics.
- neoeldex 10y agoRealtime often means: when there's not enough time, dont bother. Not going as fast as possible. Which are 2 separate issues. In my opinion, at least
- wrl 10y agoHow are they two separate issues? If you don't go as fast as possible, you can get less work done before your deadline. Even with today's CPUs and the kind of parallelisation that a good DAW program will do, I still routinely see producers (myself included) hit CPU usage limits. In audio DSP, programmers have responded to the increase in CPU capacity not with higher-level languages but instead with more computationally expensive algorithms (modern filters, for example, use techniques derived from circuit simulators for solving nonlinear equations). Besides, actually writing the DSP code makes up a comparatively tiny portion of the development time. Tuning and tweaking the DSP algorithms takes far more, and designing the user interface dwarfs both. I know multiple audio products which use Lua for their UI layer because the productivity increase is so significant. And there, you don't have to worry about performance to anywhere the degree you need to in the DSP.
- iammyIP 10y agoA single GC stutter that leads to an audiple drop-out means complete failure of the audio program. The article also mentions that: "Don’t use Objective-C/Swift on the audio thread", which can be generalised to "Don't use slow scripting languages where you don't get full control of the audio threads memory layout and data scope/lifetime". Top audio synthesis also gets down to assembly by hand optimising the hot spots.
- umanwizard 10y agoHow exactly is Obj-C a slow scripting language without control of scope?
- iammyIP 10y agoAfaik obj c got some kind of garbage collection and is heaviliy tuned to use apple libs. Since it's so platform-centric, objc is out of the question for me. Maybe fast, but not as fast as c/c++. I would guess around java speed.
- umanwizard 10y agoObjective-C is compiled (to machine language, not bytecode), and does not use garbage collection (it has optional garbage collection, but this is not supported on iOS). What informs your guess that it's "around java speed" ?
- iammyIP 10y agoJust some blurry knowledge mixed with ignorance (50/50), because of its platform-centricity. It's probably a bit faster than Java though.
- usefulcat 10y agoThat's a false dichotomy. s/segfault/unhandled exception/
- usefulcat 10y agoThat's a false dichotomy. s/segfault/unhandled exception/
- ArkyBeagle 10y agosegfaults are hardly an inevitability in 'C'/C++ .
- dave2000 10y agoThey are both exactly as bad as each other in this application but at least it's always possible to avoid a segfault.