Maria Every state is one call render() function.
I am not sure I understand. render()
gets called periodically from the backend. I don't see why you would want to only read one block worth of input in state 1 and 3 before switching state.
Maria Than Bela does nothing (but pointer is left at beginning of second block in row)|
Calling audioRead()
or audioWrite()
does not cause a hardware read or write (the way it would for instance with analogRead()
or analogWrite()
on Arduino), rather it accesses a memory buffer that contains pre-sampled audio inputs or yet to be written audio outputs. The inputs are populated before render() is called, the outputs are written to the DAC after render() has returned. As such, there is no "Bela does nothing" behaviour.
Maria So when I get in third state I actually read block which was second in row, and there is no dropped blocks
I am not sure what you mean here, but if you do not call audioRead()
during one call to render()
and cache those values somewhere yourselves, then those inputs will be lost forever, so there will be a "dropped" (in the sense of lost) block. If you refer to the "x blocks dropped" warning that prints in the console, that occurs when a call to render()
takes longer than the real-world time corresponding to the number of samples. When such an error occurs, you will get a silent audio output and there is no way around it.
I am not sure I understand what you are after here, but it seems to me that if you want to avoid dropping any input frames, then state 2 - which contains long computations - would better be offloaded to a different thread. You could then push data to this other thread for processing via a pipe or shared memory.