On Sunday, 29 November 2015 at 06:18:13 UTC, Jonny wrote:

um, come on, you sit here and preach that I don't know what I'm talking about yet you can't even be right on the first sentence?

jitter is the standard deviation of the timings. Do you know what standard deviation is? It is the square root of the sum of the squares...

There is different "jitters":
https://en.wikipedia.org/wiki/Jitter see at Sampling Jitter

Audio plugins create latency if they are slow but not sampling jitter, which is a property of the sound card.

What you mean is that when a plugin is slow it create a jitter sound when the get back?

Also, if you simply removed the GC from D so it doesn't get called, then whats the point? Anyone can do that(more or less). If you used manual memory management, then whats the point? C++ already does that and does RT audio already. We know D can be made to do this already.

No, I've seen people claim exactly the reverse, that D can't do RT audio. You even do so below.

If you pause the GC so it doesn't get called a lot, then whats the point? If you run your software for 3 hours, if it going to survive or glitch?

GC isn't paused, it doesn't trigger because there is no periodic allocations.

Do you know what "design for the worse case scenario" means? While RT audio isn't life and death, it's treated that why by the professional community.

It's important to me, else I wouldn't have ensure the GC never collects.

Please stop the appeals to authority already. Unless you state who you are perhaps? Jonny the drummer.

Just because it's acceptable to you to define RT audio in some way that justifies it for you does not mean it's RT audio. I'm not saying your software isn't RT, but if you use the GC in any way what so ever, you don't have RT audio...

This doesn't make sense. If it doesn't glitch, doesn't introduce latency or jitter, then it's RT audio. You can try the plugin at home to verify that.

regardless if it behaves like RT 99.99% percent. (there is something about guaranteed *maximum* latency that you have to deal with)

Familiar with the IPlug framework? It takes locks in the audio callback. A lock isn't guaranteed to have a maximum latency, but it's very fast. That doesn't prevent successful software like KlangHelm's MJUC to work.

But wait!
JUCE is also doing that.

It turns out the two most used audio plugins frameworks out there do things that don't have maximum latency predictibility. Have you gone bugger them?

Reply via email to