4 ms·

I'd rather configure the FPU to flush denormals to zero. As to slow scripting languages - TFA was talking about determinism. A slowish scripting language could

by yosefk 10y ago

I'd rather configure the FPU to flush denormals to zero. As to slow scripting languages - TFA was talking about determinism. A slowish scripting language could give you deterministic runtime, at least as deterministic as C or assembly (interpreted Forth is a simple example), and on the other hand there's no shortage of ways to get your C or C++ code to stall for an unknown amount of cycles (TFA enumerated some.) Of course slower languages are slower, and in a faster one you're more likely to get away with stalls because you have more slack to begin with.

iammyIP 10y ago
That's new to me, wouldn't the OS be required to be deterministic to begin with, for a deterministic language to actually be deterministic? Since most OSes are not, the only thing left is raw speed (or dedicated dsp chips).
- squeaky-clean 10y ago
  > That's new to me, wouldn't the OS be required to be deterministic to begin with, for a deterministic language to actually be deterministic? Since most OSes are not, the only thing left is raw speed (or dedicated dsp chips). You can't control the determinism of the OS or user's environment, sure. But you can make sure you're not adding additional indeterminism. If the OS can't deliver stable timing, no audio app will under those circumstances. But for the times when it does, you don't want to be the only instrument popping and underrunning, while every other effect is glitch-free. Raw speed isn't really that great, because you can't process ahead of the present. If you need to provide a 128 sample buffer every 2.9 ms, it doesn't matter if a slow language takes 2.8ms, and a fast one takes 0.1ms. However, if every 10 seconds the fast language takes 10ms, you've lost 4 buffers! Consistent speed is the aim.
- marcosdumay 10y ago
  Modern OSs have some amount of predictability. If the system is not overloaded or you renice the program, you can expect it to run every couple of ticks. If there's nothing big running in parallel and your data is small enough, you can expect it to stay in cache. If you do no disk access, you can expect it not to stall. It all depends on how much latency you can accept. With enough latency, you can bufferize over anything.
- 21 10y ago
  You can also increase the priority of your thread/process. Works pretty well. On Windows, you can also mark your thread as being audio related and latency sensitive (Multimedia Class Scheduler Service)
- wolfgke 10y ago
  > That's new to me, wouldn't the OS be required to be deterministic to begin with, for a deterministic language to actually be deterministic? A large problem for deterministic timing are the cache hierarchies of modern CPUs.

by yosefk 10y ago

iammyIP 10y ago

That's new to me, wouldn't the OS be required to be deterministic to begin with, for a deterministic language to actually be deterministic? Since most OSes are not, the only thing left is raw speed (or dedicated dsp chips).

squeaky-clean 10y ago
> That's new to me, wouldn't the OS be required to be deterministic to begin with, for a deterministic language to actually be deterministic? Since most OSes are not, the only thing left is raw speed (or dedicated dsp chips). You can't control the determinism of the OS or user's environment, sure. But you can make sure you're not adding additional indeterminism. If the OS can't deliver stable timing, no audio app will under those circumstances. But for the times when it does, you don't want to be the only instrument popping and underrunning, while every other effect is glitch-free. Raw speed isn't really that great, because you can't process ahead of the present. If you need to provide a 128 sample buffer every 2.9 ms, it doesn't matter if a slow language takes 2.8ms, and a fast one takes 0.1ms. However, if every 10 seconds the fast language takes 10ms, you've lost 4 buffers! Consistent speed is the aim.
marcosdumay 10y ago
Modern OSs have some amount of predictability. If the system is not overloaded or you renice the program, you can expect it to run every couple of ticks. If there's nothing big running in parallel and your data is small enough, you can expect it to stay in cache. If you do no disk access, you can expect it not to stall. It all depends on how much latency you can accept. With enough latency, you can bufferize over anything.
21 10y ago
You can also increase the priority of your thread/process. Works pretty well. On Windows, you can also mark your thread as being audio related and latency sensitive (Multimedia Class Scheduler Service)
wolfgke 10y ago
> That's new to me, wouldn't the OS be required to be deterministic to begin with, for a deterministic language to actually be deterministic? A large problem for deterministic timing are the cache hierarchies of modern CPUs.