Hi, sorry if this is a duplicate:
The blocksize samplesPerBlock is set in prepareToPlay() on the audio processor, which I expect to be the size of the buffer being passed in to process.
Are the values being used here guaranteed to be multiples of 16 or at least 8? I couln’t find a definitive answer, and I read a lot about “buggy hosts” in this context.
I don’t think so. 441 is used a lot on Windows (as it’s 44100/100).
Whilst a power of 2 is a sensible block size, I don’t think you can assume it.
Ouch! This conflicts pretty badly with SIMD operations. Seems there is a lot more to consider than I first imagined.
Thanks for your answer!
If you absolutely need buffers with multiples of 16, you could simply use a FIFO of an adequate size and do your processing whenever it is full. You’d probably want to chose the largest multiple of 16 that’s smaller than (or equal to) the actual blocksize being used otherwise you might not have a full FIFO to process when a block is ready so won’t have anything to output.
You need to be aware of the fact that the block size may vary in-between processBlock calls. The FIFO solution is definitely the way to go though.
@ImJimmi @gustav-scholda could you please elaborate?
By only processing when the FIFO is full I would “save” samples from this buffer to process in the next buffer? Let’s say I get a weird buffer of 17 samples. Ok, I process after 16, but the last sample is stuck inside the FIFO now? This doesn’t sound right. What do I return to the output?
Look at the juce::AbstractFifo class. It takes care of all of that for you. You specify your storage, and with simple functions the juce::AbstractFifo class keeps track of everything for you. Highly recommended.
You’d have to have a latency of 16 samples, which you’d report to the host (so those that do latency compensation can adjust their timing). Then you’d output 0s for the 1st 16 samples, then output 1 actual result sample for that 17th sample (generated by the 1st sample passed in, in your example), and then the remaining buffered 16 input samples will be ready for the next process call.
Ok cool, thanks to all for explaining, seems like this is the way to go!
