Site navigation

Handling AudioIODeviceCallback failure?

General JUCE discussion
#1

Is there any way to handle errors of the audio callback failure?
“Failure” means callbacks runs out of the time. For example, let’s think in case sampling rate is 48000 and number of sample block is 1024. My callback “fails” in case it takes more than 21.333…ms( 1024.0 / 48000.0 * 1000.0)

I want something like this listener…

//at juce_AudioDeviceManager.cpp
void AudioDeviceManager::audioDeviceIOCallbackInt (const float**...)
{
    auto time = juce::Time::getCurrentTime()
    
    //JUCE codes...

    time = juce::Time::getCurrentTime() - time;

    //"limit" == numSampleBlock / samplingRate.
    if(time > limit)
    {
        failureListeners.call([](FailureListener& l) { l.IOFailed(); });
    }
}
//=========================
//My code
class MyClass : private FailureListener
{
    void IOFailed()override
    {
        //Notify .
    }
}
#2

I don’t think it would necessarily be a good idea to add that kind of handling into the Juce code itself. Why not just add that to your own code?

#3

Is your goal to do some logging about a failing callback or to work around bad sounding audio glitches?

#4

Yeah, I also don’t want JUCE to implement like the example I wrote.
It was just only the provisional code for the clarification.
I should say there would be any better way to do.

I want to know the response time of the “whole” callbacks (Consider there’re many classes that inherits juce::AudioIODeviceCallback).
If it exceeds the limit, my goal is to get the notification of the failure and survey the object’s state at the very time it fails with debugger.

#5

Do I get you right that your goal basically is to answer the question “where does my processing code spend its time when it fails to meet the timing requirements”? If that’s the case, I guess you have a logical error here:

  • If you want to examine how your callback performs under real-world conditions you obviously want a release build. I’ve been working on some heavy processing that only produces stuttering audio in a debug build because it exceeds the allowed time slot by a lot. Still it performs quite well in a fully optimised release build, so this is what you want when you care about examining if an audio callback runs without dropouts
  • If you want your approach to give you any helpful insight you want a debug build – which will lead to a super bad audio performance…

The usual approach to manage that task is to run a release build with symbols under a time profiler and see which function calls have a high impact there, inspect them specifically and try to make that piece of code better until you come to the point where you meet your timing requirements.

Does that help in some way or did I misunderstand your goals completely? I generally think that what you are asking for is quite difficult to achieve because an exact time measurement would create some overhead that might then even be the source for an audio performance decrease

1 Like
#6

Thanks PluginPenguin, you exactly get what I intend to!
I learned a lot from your post. Really interesting.
And I now agree with your opinion.

So… it seems a lot more difficult than I expected. hmm.