Interpreting Oboe Tester Glitch test results

[rossco-50]

3rd UPDATE 21/10/21

Hi
I realise my queries may not be well put or relevant to the forum. However as it was suggested that I post here, I will try one more time. I managed to change the burst size recognised in oboe tester to 240 from 256. With the change the auto glitch test does "pass" most tests / sample rates, although not with glitches. The number of passed tests is highest when the system volume is at around 10 steps out of 25. The system gain overall is too high due to make-up from the audiofx system eq app (I turn it off).

Loopback latency has dropped from 32 ms to 27 ms.

However, listening to music in spotify I can hear audible glitches, and really bad when I switch the screen off/on and to a lesser extent switching apps and multitasking. It improves slightly when changing power mode to performance rather than balanced.

I have attached my oboe tester auto glitch results.

What could be the cause of this? I attempted a systrace but have not yet understood what I am looking for. Any advice would be gratefully appreciated.

Thanks,
Ross
Oboetester_glitch results.txt

UPDATE:

Hi
I have an update! I tested a version of Android 7.1 on the same tablet. All glitch tests were passed at all sample rates - no issues. The burst size was 240 in 7.1 and superpowered latency test data shows this burst size (or multiple e.g. 960) for all android versions for SMP600.
.... [removed for readability of most relevant points]

smp600_oboe_tester.pdf

PREVIOUS MESSAGE:
Hi

I was hoping others may be able to help me interpret the auto glitch test results from oboe tester and suggest what would improve the audio, which I am finding to be glitchy?

I have a sm-p600 (2014 tablet) with a testing version of lineageos (android 10) and the developer is responsive to improvements.

I have made the AOSP loopback dongle circuit which I believe is working OK.

By default the gain of the system was too high and volumes were distorting - I have reduced and distortion has measurably improved (used a scope on a sine wave). SNR seems low now, obviously linked to volume. Can anyone advise what is going on here and if you see a way to ensure highest SNR and glitch free audio? Is it likely that the device is limited to 48khz only despite the defined device?

Kind regards,
Ross
Glitch_vol_50%.txt

[philburk]

I realise my queries may not be well put or relevant to the forum.

Anything Oboe (or AAudio) related is relevant.

I managed to change the burst size recognised in oboe tester to 240 from 256.

That will require changing the Android audio framework or HAL. If you do this you have to be careful that ALL of the buffer sizes are updated. For example the DSP may still be operating at a 256 frame burst even if the HAL says 240.

With the change the auto glitch test does "pass" most tests / sample rates, although not with glitches.

What does that mean? Do you mean some tests fail because of glitches. There are some known problem with 11025 Hz.

From the AutoGlitch test results, it seems like there are glitches caused by random system preemptions.
Do different tests fail when you rerun the AutoGlitch test? That would indicate random preemption rather than a corrupt data path.
Do the glitches decrease when in Airplane Mode? If so, maybe a WiFi driver is disabling interrupts.

When using the Manual glitch test, are the glitches periodic, like every 5 seconds? That may indicate that some periodic task is preempting the audio.

Here is information for using SysTrace"
https://developer.android.com/topic/performance/tracing
Look to see what other tasks are running when your audio task is preempted.

a testing version of lineageos

We do not have the resources to support custom versions of Android. So I will mark this as "Answered".

[rossco-50]

Thank you for the reply.

What does that mean? Do you mean some tests fail because of glitches. There are some known problem with 11025 Hz.

Sorry there was a typo. I meant "not without glitches" - basically many of the 'passes' still had gltiches within the 10 second test.

Do different tests fail when you rerun the AutoGlitch test?

Yes. Not completely different, but different ones can fail each time.

Do the glitches decrease when in Airplane Mode?

Not obviously.

I played a 10 second sine wave 48khz wav file using foobar2000 with airplane mode turned on and took a systrace. I turned the screen off, then on, to ensure audible glitches. I can see system warnings for scheduling delays. Perhaps ridiculous to ask, but is there anything standing out here on the systrace? https://drive.google.com/file/d/1zfnZXq86XG5_d0OjGc4J0Esk1YFEYNjz/view?usp=sharing

Ross

[rossco-50]

I realised that getting a systrace of oboe tester may be more useful and a comparison with the tester results may illuminate.
I find it hard to interpet the oboe tester traces in relation to glitches. There seems variations between the periodic events?
The audioserver is jumping around a lot between different CPUs, not sure if this would indicate anything related to glitches?
Surfaceflinger seems very active and the HIDL composer callback and hardwear sensors also show more significant activity.
The OS has a system app called AudioFX which provides an interface to the DSP effects. It is turned off, but the app is stall installed and appears to do something every ~200 ms
Oboe tester glitch results.txt
parfetto file

Any guidance in interpreting how oboe tester appears and may be influenced in the trace, would be very gratefully appreciated.

[rossco-50]

Hi
I have continued to try to understand oboe tester glitch results in systrace in relation to the advice given.
In oboe tester nearly all of the glitches (considered to be delays of ~2ms to "runnable" audio porcesses being assigned CPU) are linked to the cfinteractive govenor and its associated kswticher threads which take all CPU time.
This happens in spotify playback too, but pales in comparison to the influence of surfaceflinger which is active every 10 ms and services related to the hardware lights and sensors (assuming screen brightness sensor) where switching the display off and on increases glitches significantly. Health, power and a google service also block at times too.
Whist it is possible some of these are running when they shouldn't it seems more likely to be what you said Phil - audio is not interrupting when it should. I have attached a full but hopefully quick to look at summary of my analysis and would appreciate any comments on errors I have made in thinking and what the underlying cause could be.

Oboe_tester_systrace_audio_glitches.pdf
fullanalysis_systrace.pdf

I note in both oboe tester and spotify playback the same pattern of fastmixer, AudioOut_D and writer activity. Fastmixer fires 2 times every 4 ms, 'writer' 3 short bursts every 4 ms and AudioOut once every 17 ms. Are the fastmixer and writer activities indicative of solid data path or should I look further at burst sizes etc?

Ross