BlockSize and BufferSize


#1

I just wondered - Is there any guarantee that the size of the AudioSampleBuffer in AudioProcessor::ProcessBlock is always smaller or equal to the blocksize?
I know it should be but I would like to be on the safe side.
Thanks!


#2

If the host later uses a larger buffer size than what was given for the prepareToPlay call, then the host is broken. So I would imagine it is possible, but you can consider it a situation that is not your problem. Or consider it a problem that you don’t have to deal with in a particularly elegant manner.


#3

Unfortunately you can’t assume that all hosts are sane. I would assume that it’s a rare event and do as @Xenakios suggests - handle it as simply as possible.


#4

Thanks!
that is exactly what I did not want to hear. I hate to add overhead to my code that will only benefit a very small number of misbehaving hosts.


#5

Welcome to the world of plugins!

What you really want to do is avoid a crash so you might be able get away with just checking if the block size is larger than that set in prepareToPlay and bailing out of your processBlock if that is the case. Your plugin will be silent but at least it won’t crash.

If you really want to you could display some message to the user about the misbehaving host…


#6

i always used double. Pretty sure that’s what Jules recommended too.


#7

For the past 10+ years, we’ve relied on the rule that the passed size is never bigger and we have NEVER had a problem. Using double or checking is plain paranoia and completely unnecessary.


#8

Same than reFX, if a host ever does really something that dumb, you can send an insult letter to the devs :slight_smile:


#9

My two cents: I think hosts reporting the “expected” bufferSize is not as bad as you may think:

  • You really want to know the buffer size that your callback will receive most of the time, so that you can optimise your resources to operate at this buffer size. If hosts would always report the maximum buffer size then that would include the odd large block outlier and your plug-in would optimise it’s resources to the wrong size (and likely use more memory than really necessary)
  • It’s easy enough to write a quick wrapper function around your real “processBlock” method which divides too large blocks into several smaller ones.

#10

+1 to Fabian’s comment.

Given that your code must cope with smaller blocks, then you already have the code you need to process bigger ones in chunks. It’s trivial to write this and has practically zero overhead (literally zero on some CPUs thanks to predictive execution).


#11

Any reason not to include such a wrapper function in juce already, so that we are sure we don’t receive anything larger than the “expected” bufferSize?


#12

If this should be implemented I’d also say it should be done inside the wrappers.

But then again, since this doesn’t seem to be an issue in the first place (I too can’t remember any host initialising with a blocksize that is smaller than the one used later) I wouldn’t bother at all.


#13

Seriously, I have never encountered any case of a bufferSize in the processBlock which is higher than the one provided in the prepareToPlay. Ever.

However, very often you see more or less random sizes provided in the processBlock (all the time in FL Studio or Logic for example, sometimes in other ones in offline/rendering processing mode), which can be in average two times lower than the one in the prepareToPlay. That’s something critical to take into account in some algorithms such as convolution engines, and I’m not sure there is a solution or wrapping that is going to be optimal for all the cases. In general I just don’t care, and sometimes I write a specific way to deal with it.

But I really don’t see the point at all to consider the case where the processBlock size is higher than the prepareToPlay size.


#14

it never happened but that doesn’t mean it never will
I don’t see any reason not to be prepared for it, and as Jules said “It’s trivial to write this and has practically zero overhead”


#15

All previous posts talked about plugins, where the block size is set by the DAW the plugin runs in.

Now what’s about standalone audio applications, where getNextAudioBlock gets called by the operating system if I get it right? Is there any guarantee that the block size matches the size set trough the deviceManager? Or if not, is there any particular behavior that can be expected on OS X, Linux and Windows (however, Windows is not that important for my particular project), eg. only bigger/smaller block sizes or something like that?

I did a short test on OS X, so far there was no processNextAudioBlock call with a different block size, but I won’t rely on this if it’s no guaranteed behavior.


#16

I suppose that smaller block sizes are mandatory if parameters need to be changed between 2 calls (typically automated parameters).