I’m curious about the default block size being 4 for default daisy projects. Obviously the daisy is not some modern computer and is not going to have buffer sizes like that (I believe the daisy’s max is 256?), but 4 seems lower than even the daisy can handle? I’m wondering if that default value is just to make sure it can work with whatever people are doing, but if it’s something that’s recommended to push up to maybe 48 or something if you find your code can handle it. Would love some clarification on this!
Depending on how much processing you’re doing, Daisy can use buffer size 1.
‘Best’ is up to you.
Where do you see the default of 4? I thought the default was 48.
eg. libDaisy/src/daisy_seed.cpp at master · electro-smith/libDaisy · GitHub
I feel like it used to be 48 but now it’s definitely 4 when I create a new project using helper.py. Also in all the daisyExamples projects they are all 4 too DaisyExamples/seed at master · electro-smith/DaisyExamples · GitHub
Yes, it used to be 48.Yes, it’s now 4, in the examples and projects created with helper.py.Yes, it’s still 48 in the board files for Seed, etc.
My guess is that it was changed to 4 to raise the noise frequency from callbacks to 12kHz.
2 Likes
Very interesting! Sad that it’s a problem with the noise, but here we are…
To try and give some background as what buffer sizes in general mean regarding performance and latency/delay.
On one hand, big buffers mean less overhead (more cpu cycles can be dedicated to processing audio), on the other hand it means a longer delay until the audio is processed and you get to hear it. So you have to come to some sort of middle ground where both overhead is low enough and delay is short enough.
Now, as @tele_player wrote, the likely reason for defaulting to 4 is to limit noise created by the circuit. So this whole discussion might be moot and 4 is the best choice…
Anyway! The discussed 4 cycles is actually crazy small. With 48khz sample rate a delay of 4/48k = 0.08ms will be incurred. Tiny! Of course if it’s an effect processor with both input and output the buffering delay will be added on both ends, thus 0.16ms. Still extremely short!
A good comparison is with the speed of sound in air, 340m/s. In other words, sound takes approximately 3ms to travel 1 meter (3 and some feet), so 0.16ms is absurdly short. Some say 20ms is around where some people can detect realtime latency.
Buffers with 4 cycles will mean big overhead. The cpu will spend a LOT of cycles preparing each buffer before the actual audio processing can occur. For performance and delay reasons it would be perfectly fine to use buffers of say 64 cycles.
There’s ’group delay’ also, which increases the latency a bit, but even with the extra overhead of the small buffer, you can do a lot of processing.