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.
https://github.com/olilarkin/wdl-ol/blob/cb51edc105c6cc927530a6ac0459dcee0097a23c/WDL/IPlug/IPlugVST3.cpp#L341
But wait!
JUCE is also doing that.
https://github.com/julianstorer/JUCE/blob/master/modules/juce_audio_plugin_client/VST/juce_VST_Wrapper.cpp#L582
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?
