How to detect stuttering?

You can just show the user the % utilization in a meter, and let them manage it appropriately.

Wasn’t it claimed above that for some networks you start to get problems when the CPU gets a little high whereas others can perform reliably while consistently using over 90% of CPU - and that the user would “learn” which is which? That seems a little hard on the poor user!

But the user can hear the dropouts if it gets to that point,

This is absolutely not the case. It’s possible to significantly damage sound quality and still not make it obvious to even a trained ear that this is happening - which would make no difference except that in a later stage of your processing everything suddenly sounds terrible.

An example from old digital audio days… we were wondering why the recording from our DAT sounded awful when we transferred it, as listening to the DAT on the speakers sounded great! It turned out that our “coax” cable was in fact a Plain Old RCA cable - such a cable, used for SPDIF transfers, introduces internal reflections into the signal, resulting in errors and jitter. Everyone involved had good ears and we’d even been in the room when the transfer went on, but there were no dropouts and all three of us missed it until the next step. Luckily we still had all the earlier material!

Another example is poor digital filters which screw up your phase coherence. They might sound quite nice in stereo and then exhibit dramatic problems once you mixed the signal to stereo.

In the DAT days, you learned quickly to monitor the error rate on your tapes and transfers - because the error rate would tell you something was wrong before your ears did.

A professional product should display a red light before the problem is audible.

In practical terms, I don’t think that it is possible to reliably detect dropouts algorithmically.

What’s wrong with my strategy above?

Let’s make it concrete.

For each digital signal path system, not necessarily linear or even a tree, define a signal point as a point in your digital audio which is executed exactly once for each sample passing through your system, and attach to it a 64-bit integer representing the number of samples through that point.

You can conceptually think of incrementing a counter each time a sample passes a point in the code, though in the real world you’d probably pull that increment up and increment it once per block.

We add a final signal point called the terminal point, which is simply “time * sample rate” - in other words, the “sample point” corresponding to your DSP hardware output.

If we were doing all computations one sample at a time, then all these numbers would always be the same. In any non-trivial situation, we have different block sizes, different latencies or different threads at different points, so the differences between the signal point counters vary over time.

However, in a system that is not CPU starved, these differences will always stay bounded. In a system that IS CPU starved, where audio computations fall behind the real world ones, then some of these differences will grow “without bound”.

In fact, I think it’s possible to show that, for reasonable choices of chunk size, any differences of three or more chunks even hit just one time means that you are not making your targets somewhere. I’ll have to experiment of course…

And this is very easy to do. First, you don’t have to test every pair, you simply need to test each one against the next (wrapping around). Only one thread ever writes a given sample count, so you can skip locking if you don’t mind occasional detection errors.


The above file illustrates an issue I’ve been chasing for three days now.
It’s a 40hz wave file being played in Windows Media Player while my app is running. Audio on my app is turned down so it’s not contributing it’s audio output to the mix. I get the same type of distortion in my app but think it’s likely more revealing that My App causes the issue to be manifested in another app.
In the file I close my app and it gets really nasty during the close, ad then clears completely as soon as my app completes closure.
My app is running ASIO. Don’t seem to have issues if my app is running Windows Audio.
I’ve searched the forum and tried bypassing all my audio callback processing with the exception of generating a 40 hz test tone, but my understanding from this post is that no amount of screw ups in my app should cause another app to produce this type of distortion.
The distortion hi highly variable ranging from occasional static to a wide rage of repeating phenomenon as shown here.
Any input or suggestions greatly appreciated !
Lacy