Is there an Audio Buffer in Mozzi?

[João Tragtenberg]

Hello I looked through the Mozzi library code and I couldn’t find where I could define the Buffer size.
Does it work with a buffer with a predefined number of audio samples? Or is processing just done in the time between one sample and another?

[Mr Sensorium]

Hi, the audio buffer is an instance of the class from CircularBuffer.h, called "output_buffer" in MozziGuts.cpp. The CircularBuffer class has a hard-coded size of 256, for execution speed. You'll need to code the class differently if you change the size, as it uses some bit arithmetic for advancing the pointers. There's not much to it, so it won't be hard to experiment.

…

On 8 Jul 2020, at 12:19 pm, João Tragtenberg ***@***.***> wrote: Hello I lloked through the Mozzi library code and I couldn’t find where I could define the Buffer size. Does it work with a buffer with a predefined number of audio samples? Or is processing just done in the time between one sample and another? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#92>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANW2N7KUTQ4HVNXQPKVV6DR2PJTBANCNFSM4OUBV5KQ>.

[João Tragtenberg]

So the buffer has the size of one sample. Was there a reason for that choice? If there was a buffer with 16 audio samples, instead of having 61 microseconds to process each sample, we could have 976us or even 1,9ms using a buffer with 32 audio samples. It would take longer to fill and read the buffer, the amount of time to process the signal would increase dramatically, wouldn't it? It would even be possible to make more elaborate processing with a 32768 Hz sample rate.
To implement it I believe it would be better to have another circular buffer holding the last N item[] arrays from the current circularBuffer, but I don't understand much about optimising C code. What do you think about it?

[Mr Sensorium]

The buffer has a size of 256 audio samples, giving about 15ms latency at 16384Hz. You can look at the code in CircularBuffer.h.

…

On 9 Jul 2020, at 12:09 am, João Tragtenberg ***@***.***> wrote: So the buffer has the size of one sample. Was there a reason for that choice? If there was a buffer with 16 audio samples, instead of having 61 microseconds to process each sample, we could have 976us or even 1,9ms using a buffer with 32 audio samples. It would take longer to fill and read the buffer, the amount of time to process the signal would increase dramatically, wouldn't it? It would even be possible to make more elaborate processing with a 32768 Hz sample rate. To implement it I believe it would be better to have another circular buffer holding the last N item[] arrays from the current circularBuffer, but I don't understand much about optimising C code. What do you think about it? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#92 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANW2N2D6JCYC2UTJ4ZOBITR2R4Z7ANCNFSM4OUBV5KQ>.

[João Tragtenberg]

Oh, that is good to hear, thank you.