# AudioSampleBuffer realtime-problem

**URL:** <https://forum.juce.com/t/audiosamplebuffer-realtime-problem/7817>\
**Category:** General JUCE discussion\
**Created:** [December 6, 2011, 9:28am UTC](https://forum.juce.com/t/audiosamplebuffer-realtime-problem/7817 "2011-12-06T09:28:22Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![zamrate](https://avatars.discourse-cdn.com/v4/letter/z/f4b2a3/32.png) [@zamrate](https://forum.juce.com/u/zamrate)\
**Post date:** [December 6, 2011, 9:28am UTC](https://forum.juce.com/t/audiosamplebuffer-realtime-problem/7817/1 "2011-12-06T09:28:22Z")

</div>

In my audioCallback I use the AudioSampleBuffer class a lot to reference already existing audio data (so it’s already allocated), using AudioSampleBuffer (float\*\* dataToReferTo, int numChannels, int numSamples).

Upon deletion, AudioSampleBuffer deletes a HeapBlock which again leads to a call of free() (and ofcourse its constructor also malloc’ed). Not exactly good if you have a AudioSampleBuffer in your audioCallback. Here it ruined all performances.  
Since JUCE relies heavily on AudioSampleBuffer, this can cause heavy potential problems.

[code] ILSequencer.exe!free(void \* pUserData=0x00000000) Line 49 + 0xb bytes C++  
ILSequencer.exe!juce::HeapBlock\<char,1\>::~HeapBlock\<char,1\>() Line 119 + 0xb bytes C++

> ILSequencer.exe!juce::AudioSampleBuffer::~AudioSampleBuffer() Line 147 + 0x19 bytes C++  
> ILSequencer.exe!MainController::audioDeviceIOCallback(const float \* \* inputChannelData=0x06bc5ec8, int numInputChannels=0x00000002, float \* \* outputChannelData=0x06bc6e30, int numOutputChannels=0x00000002, int numSamples=0x000001c0) Line 624 + 0x1e bytes C++[/code]

---

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\
**Post date:** [December 6, 2011, 10:00am UTC](https://forum.juce.com/t/audiosamplebuffer-realtime-problem/7817/2 "2011-12-06T10:00:00Z")

</div>

Ok, well don’t create one in your audio thread then!

Just create a big enough buffer in your prepareToPlay method, and re-use it!

---

<div class="post-metadata">

**Author:** ![zamrate](https://avatars.discourse-cdn.com/v4/letter/z/f4b2a3/32.png) [@zamrate](https://forum.juce.com/u/zamrate)\
**Post date:** [December 6, 2011, 10:06am UTC](https://forum.juce.com/t/audiosamplebuffer-realtime-problem/7817/3 "2011-12-06T10:06:50Z")

</div>

OK, well maybe add a notice that this class should never be used for realtime. Because in former versions of JUCE this was not a problem.

---

<div class="post-metadata">

**Author:** ![zamrate](https://avatars.discourse-cdn.com/v4/letter/z/f4b2a3/32.png) [@zamrate](https://forum.juce.com/u/zamrate)\
**Post date:** [December 6, 2011, 10:14am UTC](https://forum.juce.com/t/audiosamplebuffer-realtime-problem/7817/4 "2011-12-06T10:14:43Z")

</div>

And btw, aren’t you doing exactly the same thing as myself in GraphRenderingOps::ProcessBufferOp::perform() ?

[code]void perform (AudioSampleBuffer& sharedBufferChans, const OwnedArray & sharedMidiBuffers, const int numSamples)  
{  
for (int i = totalChans; --i \>= 0;)  
channels[i] = sharedBufferChans.getSampleData (audioChannelsToUse.getUnchecked (i), 0);

```
    AudioSampleBuffer buffer (channels, totalChans, numSamples); // <------------ will result in free()/malloc()

    processor->processBlock (buffer, *sharedMidiBuffers.getUnchecked (midiBufferToUse));
}[/code]
```

---

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\
**Post date:** [December 6, 2011, 10:39am UTC](https://forum.juce.com/t/audiosamplebuffer-realtime-problem/7817/5 "2011-12-06T10:39:52Z")

</div>

> [@](#):
>
> Because in former versions of JUCE this was not a problem.

Erm… no, it’s always been the same. The class has to allocate memory, so it has to call malloc, there was never a version that didn’t do so. In fact the older versions used to make more calls to malloc than the current one does.

> [@](#):
>
> And btw, aren’t you doing exactly the same thing as myself in GraphRenderingOps::ProcessBufferOp::perform() ?

No. Try stepping through the code and see what really happens in there.

---

<div class="post-metadata">

**Author:** ![zamrate](https://avatars.discourse-cdn.com/v4/letter/z/f4b2a3/32.png) [@zamrate](https://forum.juce.com/u/zamrate)\
**Post date:** [December 6, 2011, 11:27am UTC](https://forum.juce.com/t/audiosamplebuffer-realtime-problem/7817/6 "2011-12-06T11:27:44Z")

</div>

Why would AudioSampleBuffer need to allocate memory when used with the constructor AudioSampleBuffer (float\*\* dataToReferTo, int numChannels, int numSamples) ?? I’ve been clearly saying that I am only referencing pre-allocated memory, and not letting AudioSampleBuffer allocate anything!

---

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\
**Post date:** [December 6, 2011, 11:31am UTC](https://forum.juce.com/t/audiosamplebuffer-realtime-problem/7817/7 "2011-12-06T11:31:17Z")

</div>

> [@](#):
>
> I’ve been clearly saying that I am only referencing pre-allocated memory, and not letting AudioSampleBuffer allocate anything!

Ah, sorry then! I have to skim these forum posts pretty quickly, you know!

Just looking at your first stack trace again, the “free” call is actually freeing a null pointer, so surely the standard library won’t invoke a lock if you pass it a null pointer… would it??

---

<div class="post-metadata">

**Author:** ![zamrate](https://avatars.discourse-cdn.com/v4/letter/z/f4b2a3/32.png) [@zamrate](https://forum.juce.com/u/zamrate)\
**Post date:** [December 6, 2011, 11:37am UTC](https://forum.juce.com/t/audiosamplebuffer-realtime-problem/7817/8 "2011-12-06T11:37:00Z")

</div>

You’re right, calling free(0) should actually not take too much time… That’s strange… Could it have something to do with the leak detector?

---

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\
**Post date:** [December 6, 2011, 11:43am UTC](https://forum.juce.com/t/audiosamplebuffer-realtime-problem/7817/9 "2011-12-06T11:43:03Z")

</div>

> [@](#):
>
> Could it have something to do with the leak detector?

Yes, it definitely could!

---

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\
**Post date:** [December 6, 2011, 11:44am UTC](https://forum.juce.com/t/audiosamplebuffer-realtime-problem/7817/10 "2011-12-06T11:44:35Z")

</div>

…hang on - you do mean the Visual studio leak detector, right? Not my juce leak detector, which certainly won’t have any connection with this.

---

<div class="post-metadata">

**Author:** ![zamrate](https://avatars.discourse-cdn.com/v4/letter/z/f4b2a3/32.png) [@zamrate](https://forum.juce.com/u/zamrate)\
**Post date:** [December 6, 2011, 11:56am UTC](https://forum.juce.com/t/audiosamplebuffer-realtime-problem/7817/11 "2011-12-06T11:56:20Z")

</div>

I meant any leak detector. Anyway, I guess problem solved. It’s not your fault, so sorry for the hassle.

---

<div class="post-metadata">

**Author:** ![zamrate](https://avatars.discourse-cdn.com/v4/letter/z/f4b2a3/32.png) [@zamrate](https://forum.juce.com/u/zamrate)\
**Post date:** [December 6, 2011, 12:06pm UTC](https://forum.juce.com/t/audiosamplebuffer-realtime-problem/7817/12 "2011-12-06T12:06:32Z")

</div>

Last question: Is there any way to alert when calls to free/malloc/new/delete are made in the audio thread? It would help a lot if that would be possible.

---

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\
**Post date:** [December 6, 2011, 12:17pm UTC](https://forum.juce.com/t/audiosamplebuffer-realtime-problem/7817/13 "2011-12-06T12:17:38Z")

</div>

There’s no easy way to do that, I guess you could create your own DLL to intercept them, check the thread ID, etc. but it’d be messy.

---

<div class="post-metadata">

**Author:** ![otristan](https://avatars.discourse-cdn.com/v4/letter/o/f0a364/32.png) [@otristan](https://forum.juce.com/u/otristan)\
**Post date:** [December 6, 2011, 1:09pm UTC](https://forum.juce.com/t/audiosamplebuffer-realtime-problem/7817/14 "2011-12-06T13:09:43Z")

</div>

I use something like that

[code]  
static juce::Thread::ThreadID gpAudioThreadId = NULL;

#include   
void \*operator new(size\_t size) throw(std::bad\_alloc)  
{  
assert(gpAudioThreadId == NULL || gpAudioThreadId != juce::Thread::getCurrentThreadId());  
void \*p = malloc(size);

if (!p)  
{  
throw std::bad\_alloc();  
}

return p;  
}

void operator delete(void \*p) throw()  
{  
assert(gpAudioThreadId == NULL || gpAudioThreadId != juce::Thread::getCurrentThreadId());  
free§;  
}

void \*operator new(size\_t size, const std::nothrow\_t &) throw()  
{  
assert(gpAudioThreadId == NULL || gpAudioThreadId != juce::Thread::getCurrentThreadId());  
return malloc(size);  
}

void operator delete(void \*p, const std::nothrow\_t &) throw()  
{  
assert(gpAudioThreadId == NULL || gpAudioThreadId != juce::Thread::getCurrentThreadId());  
free§;  
}

void \*operator new[](size\_t size) throw(std::bad\_alloc)  
{  
assert(gpAudioThreadId == NULL || gpAudioThreadId != juce::Thread::getCurrentThreadId());  
void \*p = malloc(size);

if (!p)  
{  
throw std::bad\_alloc();  
}

return p;  
}

void operator delete[](void \*p) throw()  
{  
assert(gpAudioThreadId == NULL || gpAudioThreadId != juce::Thread::getCurrentThreadId());  
free§;  
}

void \*operator new[](size\_t size, const std::nothrow\_t &) throw()  
{  
assert(gpAudioThreadId == NULL || gpAudioThreadId != juce::Thread::getCurrentThreadId());  
return malloc(size);  
}

void operator delete[](void \*p, const std::nothrow\_t &) throw()  
{  
assert(gpAudioThreadId == NULL || gpAudioThreadId != juce::Thread::getCurrentThreadId());  
free§;  
}[/code]

and assign  
gpAudioThreadId = juce::Thread::getCurrentThreadId();  
at the top level of the audio callback

HTH