4 ms·

I can indeed see this being useful for realtime audio. I spent a lot of time trying to optimize IPC performance while making a 32 - 64bit bridge for audio plugi

by pierrec 11y ago

I can indeed see this being useful for realtime audio. I spent a lot of time trying to optimize IPC performance while making a 32 - 64bit bridge for audio plugins. I used a related hack that allowed me to reduce inter-process synchronization latency to zero (though that phrasing might be disputable). The hack was essentially that whenever the host requested an audio block from a plugin, it would get the output not for that block but for the previous block instead. This introduced a fixed audio delay for bridged plugins, but it eliminated IPC latency, so even complex tracks with lots of bridged plugins wouldn't stutter. Thankfully I don't put up with any of this now that all the software I use works correctly in 64 bit. Still, latency is often a huge PITA with realtime audio. What's interesting is that as processors get faster, audio plugin makers publish stuff that uses more and more processor. So much that I'm now considering getting one of those new 16-core processors for my next workstation.

wallacoloo 11y ago
> What's interesting is that as processors get faster, audio plugin makers publish stuff that uses more and more processor. Uggh. I know how you feel. For a while now, I've wanted to create some sort of audio processing engine (either a very versatile LADSPA/VST/AU/etc plugin or a minimal DAW) wherein all the different components that usually run their own code to generate/process audio are described as data instead (e.g. transfer functions), and then the host decides how to actually compute the audio. This would give lots of room to try new optimizations that aren't usually possible, and you only have to optimize one area of critical code, rather than optimizing each individual plugin. This is especially beneficial when trying to make conditional use of processor extensions like SSE.
- enqk 11y ago
  Have a look at the Faust project: http://faust.grame.fr http://faust.grame.fr
- Kristine1975 11y ago
  This sounds a bit like what Mac OS X's CoreImage does for pixel transformations: https://en.wikipedia.org/wiki/Core_Image https://en.wikipedia.org/wiki/Core_Image Instead of applying a series of filters individually, Core Image assembles a dynamic instruction pipeline so that only one calculation needs to be applied to the pixel data to achieve a cumulative effect... Regardless of the number of filters, Core Image assembles the code for this instruction pipeline with a just-in-time compiler

by pierrec 11y ago

wallacoloo 11y ago

> What's interesting is that as processors get faster, audio plugin makers publish stuff that uses more and more processor. Uggh. I know how you feel. For a while now, I've wanted to create some sort of audio processing engine (either a very versatile LADSPA/VST/AU/etc plugin or a minimal DAW) wherein all the different components that usually run their own code to generate/process audio are described as data instead (e.g. transfer functions), and then the host decides how to actually compute the audio. This would give lots of room to try new optimizations that aren't usually possible, and you only have to optimize one area of critical code, rather than optimizing each individual plugin. This is especially beneficial when trying to make conditional use of processor extensions like SSE.

enqk 11y ago
Have a look at the Faust project: http://faust.grame.fr http://faust.grame.fr
Kristine1975 11y ago
This sounds a bit like what Mac OS X's CoreImage does for pixel transformations: https://en.wikipedia.org/wiki/Core_Image https://en.wikipedia.org/wiki/Core_Image Instead of applying a series of filters individually, Core Image assembles a dynamic instruction pipeline so that only one calculation needs to be applied to the pixel data to achieve a cumulative effect... Regardless of the number of filters, Core Image assembles the code for this instruction pipeline with a just-in-time compiler