Re: Graillon 1.0, VST effect fully made with D

2015-11-29 Thread Warwick via Digitalmars-d-announce

On Sunday, 29 November 2015 at 09:12:18 UTC, Any wrote:

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...


Jitter is any deviation in, or displacement of, the signal 
pulses in a high-frequency digital signal. The deviation can be 
in terms of amplitude, phase timing or the width of the signal 
pulse.


The units of jitter measurement are picoseconds peak-to-peak 
(ps p-p), rms, and percent of the unit interval (UI).


See google.


We're talking about whether a plugin / audio code / runtime 
environment can deliver audio to a soundcard in a reliable manner 
so that you don't get audio drop outs. We're not talking about 
the jitter of a digital clock source that's used to control the 
actual sampling stream. It's similar but at the level of the 
audio buffer timeslice, not the unit delta of the sample stream. 
The jitter of an audio clock source is for electronic engineers 
not audio plugin developers.


In general terms of delivering audio to a soundcard jitter would 
be the variation in the time take to deliver each buffers worth 
of audio data to the soundcard. If the sound card has 5ms 
latency, then you need to make sure your audio processing never 
takes more than that.


The point is that it is better to have an algorithm that always 
takes 3ms, than one that usually takes 2ms but occasionally takes 
6ms. Because those times when it takes 6ms it cant feed the 
soundcard in time for the next audio buffer to be delivered.


In more precise terms jitter is the variation in the time a given 
algorithm takes to process. I mean if the code is identical and 
doesn't change from one buffer to the next, the variation in time 
take to produce a each buffers worth of data.


It's important to remember that a typical DAW user may have 10, 
20, or 100+ plugins loaded, and it may be hitting 80 or 90 
percent CPU usage in places. With constantly changing loads on 
the plugins.


IE. If you are at 90% cpu usage with 5ms timeslice you can only 
tollerate 0.5ms jitter before the shit hits the fan. So the 
important question is not "does it work", it's "does it work 
under heavy load".






Re: Graillon 1.0, VST effect fully made with D

2015-11-28 Thread Warwick via Digitalmars-d-announce
On Saturday, 28 November 2015 at 11:35:56 UTC, Guillaume Piolat 
wrote:
On Saturday, 28 November 2015 at 02:37:40 UTC, Marco Leise 
wrote:
We can probably agree that we don't know about the impact on a 
large multimedia application written in D. What you can 
communicate is: Create a @nogc thread routine and don't 
register it with the GC to write real-time VSTs.


Guillaume did a good job, taking the GC out of the real-time
thread. It's D, it is a bit of a hack, it's the correct way to
do it and works. But I don't see it debunking any myths about
GC and real time...
A) It doesn't mix them to begin with.
B) "Realtime GCs" are a thing. D's GC is not optimized for
   such a use case.
C) With a small heap it doesn't matter. (We need more complex
   multimedia projects.)



But the claim we hear on Internet forums is:

- "can't do realtime with a GC language" (wat)
- "GC leads to GC pauses" (only if you let them happen)

Which is imho a shortcut.


Just to play devils advocate... you haven't proved GC can do real 
time if you achieve it by quarantining the real time code from 
the GC.


It's kind of like saying you can climb a mountain on a bycicle if 
you get of an carry it on the bits that are too steep.


That said, the basic idea is that you shouldn't do anything that 
might take too long or use any mutex / locks. That is the same 
whether you use C++, Pascal, or D.


The real story is how easy D makes it to achieve that.