In this tutorial, if in the first while loop, samplesThisTime is outputSamplesRemaining, then outputSamplesRemaining will become 0, right? (so it only runs once?)[ (outputSamplesRemaining -= samplesThisTime)==0]

[Processing the audio section of this tutorial]
https://docs.juce.com/master/tutorial_looping_audio_sample_buffer.html

Yes, the while loop could run only once.

bufferSamples represents the number of samples left in audio file and outputsamples represents the amount of samples left in the current buffer. They will not be the same because the file will be thousands of samples but buffer will only be 512 or a small power of 2.
The loop always only runs once as long as bufferSamples> outputsamples, then why use while loop?

The while loop will run more than once when the number of samples left to read from the file is smaller than the size of the buffer to fill.

2 Likes

Yeah, so I’ve had the project open, but not gotten around to saying what Ed said, but essentially the size of the file in sample frames is unlikely to be an integer multiple of the block size. Often you will have a short buffer at the end of the audio loop that is less than the block size so it fills part of the audio block with the end of the loop the loops back to the start of the file and adds the remaining sample frames to the block before returning. It is true that the while() loop is likely to run only once in many cases, but sometimes more than once. Especially if the sample is some kind of short wavetable, in which case it might run more than twice, even.

In the most cases, bufferSamplesRemaining will be larger than outputSamplesRemaining, so the program will run many getNextAudioBlock with only one loop in while. And in the last block( assume bufferSamplesRemaining < outputSamplesRemaining), outputSamplesRemaining will be >0, and the position will become 0 for looping purpose. Thus, in this getNextAudioBlock, it only runs 2 loops in while. Right?

Yes, in most cases but not necessarily. For example:

There would be other approaches. Some might be “nicer” in terms of code perhaps, some might look horrible but be more optimal. I guess the main question, which is the most important, is are you saying the code is incorrect? In which case, we should suggest a fix. But it would be interesting to look at other code styles and examine some profiling for the other cases.

Sorry, there is one more example that I forgot to add here, off the top of my head. There is no guarantee (according to the API contract, i.e., it’s not mentioned as a limitation nor are there any assertions I can see other than to check the size is more than zero in some places) in any of the following that the number of sample frames is less than INT_MAX, or std::numeric_limits<int>::max() (probably 2^31 i.e., 2,147,483,648):

  • AudioBlock<Type> or AudioBlock<float>, (or the equivalent old school AudioSampleBuffer)
  • AudioSourceChannelInfo
  • AudioSouce (which is the base class of AudioAppComponent)

I admit that it might be a rare scenario where the block size is very large, especially if it is actually derived from AudioAppComponent, but if it were a pure AudioSource subclass then a host might pass a large number here if doing offline processing (again possibly unlikely but possible)