Go Down

Topic: "samplerate" question (environment) (Read 964 times) previous topic - next topic

messenger UP

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! :)


will it maintain the same steady rate until loaded with some unreasonably complex dsp?
Even simple DSP functions are probably going to bog down because the processor doesn't have any DSP instructions.

Don't send me technical questions via Private Message.


Samplerate needs to be fixed in hardware, say by using a timer interrupt.
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]

messenger UP

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 will NOT respond to personal messages, I WILL delete them, use the forum please ]


Take a look at the Arduino AudioZero library which uses a timer and an interrupt to feed data at a fixed rate to a DAC.



Go Up