FYI: AudioSampleBuffer::getSampleData

General JUCE discussion
1

Just a quick explanation of today's changes where I've deprecated the getSampleData() method of AudioSampleBuffer:

I've done this to enable an optimisation that we found very handy in Tracktion.. Until today, Tracktion had its own legacy audio buffer class, which was pretty much identical to AudioSampleBuffer, but which had an extra trick of knowing when it was completely clear, so that it could avoid a lot of overhead when you do things like adding an empty buffer to another one. We found that this happened a lot more than you'd expect, and made a big difference to performance, so since it was so useful in tracktion, I figured that it'd also be useful in the library in general. (This also meant I could refactor tracktion to use the AudioSampleBuffer class and simplify the codebase).

In order to make it possible to have a clear flag, you need to be able to mark the buffer as dirty when it gets written to, and that involves setting a flag when you get a pointer for writing, but not for reading. So I've replaced the single getSampleData method with two methods, getReadPointer and getWritePointer. When calling getWritePointer, the buffer is marked as non-empty because it assumes you're planning to alter the data, but getReadPointer leaves the flag intact. I've also found that having a method that returns a const float** is actually quite handy in terms of code readability and const-correctness.

(And my next step in refactoring this class will be to make it use different formats internally, so that it can be switched between holding its data as 32- and 64-bit floats, and possibly 32-bit ints too)

1 Like
2

it might worth mentioning in the doc that clear() should not be called (or with care) after getArrayOfWritePointers(), as that obviously may lead to some side effects making hasBeenCleared() report false positives :

    float** bufs = buffer.getArrayOfWritePointers();
    buffer.clear();
    FloatVectorOperation::add (bufs[0], something, numSamples);
// here buffer.hasBeenCleared() will still return true

sure it’s a stupid thing to do when you know about it, but it’s good to keep it in mind to avoid hard to track down bugs/wrong buffer content :slight_smile:

3

Bumping this confused me until I saw the original thread date (year)

But it did make me find two references in the code which should be removed in some comments in the header

Cheers,

Rail

4

Thanks Rail, I’ll clean those up!