Odd, jassert (currentCallback == nullptr) in ASIOAudioIODevice::Open asserts

This has been bothering me for awhile.
Juce 5.4.5
Line 397 juce_win32_asio.CPP
jassert (currentCallback == nullptr); //always asserts!

My currentCallBack is valid (It is an * AudioIODeviceCallback)

Everything works as expected (::audioDeviceIOCallback, ::audioDeviceAboutToStart and ::audioDeviceStopped are called as expected).

I cannot for the life of me figure out why the assert evaluates to true?

I am sure there are persons here smarter than I am!

Without seeing some code, it will be very difficult for anyone to help you. Please post relevant snippets, surrounded by triple tic (3 of these `)

code stays formatted within these areas

I am sorry but the code is within juce modules.
Specifically as I have stated:
Juce 5.4.5
Line 397 juce_win32_ASIO.cpp
jassert (currentCallback == nullptr);

Since we all have the code I assume that anyone can open juce_win32_ASIO.cpp and go to line 397.
Just in case:

jassert (currentCallback == nullptr);


If I do this:

         jassert (currentCallback == nullptr);

Then the jassert is never hit.
::currentCallback is valid every where else in the entire file ( juce_win32_ASIO.cpp) when running as I have set a break point on every reference to it.

I am debugging under VS 2017.
I have a hard time with #define’s such as jassert as one can not really step into them.

So, I believe this is happening:
(currentCallback == nullptr) evaluates to false (currentCallback IS valid).

jassert is located in juce\modules\juce_core\system\juce_PlatformDefs.h

#define jassert(expression)       JUCE_BLOCK_WITH_FORCED_SEMICOLON (if (! (expression)) jassertfalse;)

if(!(currentCallback == nullptr)) evaluates to true, so jassertfalse is called.

so the assertion occurs.

Again, I am at a loss and am hoping someone can point out my issue.

Not the library code, your code! lol… If you are doing something wrong, we can’t help figure that out without seeing your code.

Asserts are meant to tell you when something is wrong. They are not meant to be ignored.

I am very sorry if I am not getting my point across.
This is not my code, it is JUCE code.

The source file in question is located at:

Again, this is not my code.
If you are not building under Windows you probably will not have this file.

The point I am attempting to get across is that within the JUCE 5.4.5 code, the source file specified, the line specified I believe should be:

jassert (currentCallback != nullptr);

Perhaps you where confused because I modified the JUCE source code to show that currentCallback actually has a value.

Why don’t we just let this lie and wait for someone else respond to my question.

Thanks, and I have no intention of offending anyone here.

I am sorry if I am not getting my point across. :slight_smile: Often times when you get an assert from JUCE, it is because of how the client code is using it. Without seeing how you are using it, it is hard to help discern if it is a user error, or something wrong with JUCE. The library tends to be pretty robust, and so we first suspect user code. Maybe this relates to an object lifetime issue? Maybe something else. Anyways, I’m glad to let this lie. Best of luck. :slight_smile:

If you look, what the ASIO wrapper does here, it is:

  • close() if it was open()
  • in close it calls stop()
  • in stop() it sets the currentCallback to nullptr

When all that happened, the code concludes in the jassert to see, that the closing actually happened.

So if you want to dig in, check if close() was actually called…

The condition to catch here is, that a currentCallback was set, but the ASIO was not running.

But I have no further information, why the assert fires in your setup.

Thanks Daniel,

I have no idea why my currentCallback has a value in open() as I have not called start(). It reeks of a wild pointer. I am to the point where I am going to start re-installing things (ASIO4ALL, Juce,…) and do a clean and build.

Thanks to everyone so far for the help.