soz for a terribly early question, but an informed answer will keep me miles ahead.
i'm just starting with dev boards. i have just managed to put a waveform out the audio out pin on a trinket M0 with the arduino IDE.
i'm the oldest gnarliest audio dsp programmer in teh univers i need no help with audio dsp.
my very basic waveform sketch is giving me a pitch of just under 300Hz with a wavecycle of 1024 samples. the pitch is steady, which is great! (much better than the circuitpython on the trinket M0, terrible.) constant loop rate is critical to audio applications.
300 * 1024 = 307200, nice overhead! traditionally in audio, this would be called "samplerate" and that is what i am going to call it here.
so: i am about to amend my simple script with more complex procedures. what can i expect to happen to my samplerate/performance stability?
will it maintain the same steady rate until loaded with some unreasonably complex dsp? this is good for me, i can keep to "simple and efficient methods".
if not, what should i know about to implement a fixed operational rate for the loop() ?? can this be set with an API? i only need an overhead of ~22k.
being able to command this will be so, so beneficial to my endeavour. thanks for any help!
the experience i'm having is that the loop() process seems to run at a fixed rate per compile, but that rate varies depending on the content. i'm even finding that adding an extra multiply tips at a place and gives me a slower loop. but, functioning at a steady rate.
so, for my implementation, i will have to find equilibrium. the first simple sketch gave me an incredible samplerate around 300k, but with a procedural voice synthesis engine it went down and down per compile, i'm currently fighting about 8000 samplerate.. i'm on a border of my performance tolerance here so this trinket m0 is pulling just about enough for three formant bands, but i can probably find an optimisation. 4k nyquist is pretty cheesy.
loop() runs at no particular rate, its just called from a loop (whose only other actions are checking
for serial input - basically an empty loop() will get called 100k times a second or more easily.
If you want timing to be fixed, you have to use hardware to it, either via interrupts (common approach
for sampled systems), or by busy-waiting and checking the current time from micros().
Relying on the natural timing of the code is very fragile - an upgrade of the system could easily involve
changes to the compiler which then cause the code to be faster or slower than before without any changes
to the source.
On a more complex processor with caching the timing consistency is completely out of the window...
i need no help with audio dsp.