Additional latency with Juce audio


#1

There’s a strange latency with audio output happen in my app, when it uses Juce’s audio framework. I was initially using PortAudio library and the latencies there were strictly dependent on the audio buffer size set, what is normal. But after switched to JUCE, I discovered, that the resulting latency is twice longer than should be according to the current buffer size! I checked several times with different buffer sizes to be sure, and yeah, its around two times longer (but not exactly two times - with big buffer sizes it becomes even longer). I of course accurately checked and debugged all this to ensure that everything is okay in data.

It also looks like this delay somehow depends on audio callback nature. I tried another test on it - replaced my callback with another, that generates random noise if a trigger button is pressed and silence if not pressed. No such a big latency happen then and everything is okay, but when I use my usual callback, it does such latency independently on how much data is processed - even if a single sample is playing, the latency is the same. That’s why I’m saying it somehow depends on callback nature, not on its speed. Anyway, if the callback’s speed were the problem, there would be another result of it - buffer underruns, clicks etc, but not latency. And as I said, with PortAudio everything is okay even now, when I switch compilation defines to use PortAudio.

I tried out Juce Demo app and saw similar big latency there, but only in debug mode, when compiled it myself from sources. In release mode everything is all right. But in my app the latency absolutely the same both in debug and release builds. Quite weird, isn’t it? I also transitioned from 1.46 to 1.50 version, but this didn’t fixed the problem.

Any thoughts or suggestions on this are welcome. Thanks in advance.


#2

Oh come on… You typed all that, but didn’t think of mentioning whether it’s a Mac/PC/Linux, WASPI/ASIO/DirectSound/CoreAudio/etc…! Don’t you think that might be sort of relevant!??

BTW if you’re using DSound, all bets are off when it comes to latency - it’s absolutely hopeless and prone to losing sync.


#3

Oh, sorry, I forgot to mention - it’s PC/DirectSound/WinXP. Do you mean it could be exclusively DirectSound issue? But no other apps I test on my system have any issues with latencies in DirectSound. And this doesn’t look like sync problem - the latency just scales by about x2. When the buffer is small enough, the latency looks almost as short as in every other app.


#4

What do you actually mean when you say you’re measuring these latencies? Are you talking about an end-to-end latency or just an output latency?

In a debug build if you do anything that might block the audio thread for too long, it’s very easy for DSound to drift completely out of sync. As I said, I offer no support or sympathy for DSound, I’ve already wasted far too much of my life trying to persuade that badly-designed piece of crap work in a halfway decent manner. Switch to WASAPI if possible.


#5

I’m just hearing the latencies, not measuring them, just usual output latencies between triggering some sound in app and hearing that sound in earphones. This problem is not related to Debug builds only - in Release everything is absolutely the same.

I’m also far from being a DirectSound fan, but since no other app except my one, Juce-based, has similar latency problems with DSound, it looks pretty logical to me, that the root cause could be located in Juce code, don’t you agree?


#6

Indeed there could be something that could be tightened up, but I’ve spent a long time staring at that code and am out of ideas!

But bear in mind that when you set a buffer size for DSound, it doesn’t mean the same thing as for other, (sensible) audio APIs. DSound uses a single circular buffer, so if you set a size of “512”, I think juce multiplies that by e.g. 3, and uses that size of buffer. Other frameworks might use the size to mean the size of the entire buffer, or might multiply it by other amounts. So you can’t compare them directly.


#7