Oboe Systrace are non full buffers considered as underruns or not?

I am using oboe library to make a music app. There I produce music by writing PCM float values to the given pointer. I rarely have underruns which I can hearwhich. I also verify this with the following oboe APIs:

managedStream->getXRunCount();

The docs says the following:

 * An XRun is an Underrun or an Overrun.
 * During playing, an underrun will occur if the stream is not written in time
 * and the system runs out of valid data.
 * An underrun or overrun can cause an audible "pop" or "glitch".

I am trying to debug the issue. I found this awesome tutorial by Don. I captured a 10 seconds of systrace with the following, note that during this 10 seconds I heard 0 audable underrun pop/click sounds:

systrace.py --time=10 -o trace.html -a com.example.app audio sched freq

The result is the following by aaRdy call (blue box height shows how many sample are in the buffer, more height more sample which is wanted): This is just a small portion of the aaRdy call. There is never a time that my buffer has 0 sample is it. I checked all of it. In the article Don written, he says the following:

But then the buffer starts empty, first dropping to 96 frames, then….oh dear…to zero! At zero we are guaranteed to have an audio glitch because there’s no data in the buffer.

Here is a screenshot from the article:

My question looking at the article, I can gurantee that if the blue box is empty then there is an underrun. However, in my systrace it is never empty and I heard no underrun pop clicks BUT managedStream->getXRunCount();call actually returned 12. I am not sure if there is an underrun or not.

Does the decrease in blue boxes means that there is an underrun even when it's not 0?

Don here :)

what does it mean to have a non-full buffer in the trace.

It means that at that moment in time the audio hardware is reading (and removing) data from the buffer faster than your app is writing it.

This is a fairly normal situation if your app uses significant CPU to generate audio data. Maybe some other process on the system was prioritized over the audio thread and your app couldn't generate the required number of audio frames fast enough.

This only becomes a problem if the slow writing situation lasts long enough for the buffer to be completely emptied, and the audio device reads from the buffer while empty. In which case you'll get an underrun and the XRuns counter will be incremented.

As you rightly state, the XRuns counter will record the number of underruns (or overruns for a recording stream) for the lifetime of the stream.