Strange Audio Interruptions on Android with Miniaudio During Wake-up from Background Mode

[gungun974]

Miniaudio is a truly remarkable project because it provides me with a unified API where I can directly feed my uncompressed audio and have my system play my sound.

It works perfectly on Linux, Windows, iOS, and MacOS. However, I've noticed some strange interruptions in sound playback on Android that I can't understand why it happens when my application comes out of background mode.

Initially, I thought that the audio artifact was due to using Flutter for my UI or due to my C++ code responsible for decoding audio with libav for Miniaudio, but after experimenting in a generic Android project with just Miniaudio, C, and a simple 220Hz sine wave, I encountered the same anomalies regardless.

For your information, I have produced an audio recording and a test project that can reproduce the anomaly.

My protocol involves launching the application, turning off my phone, and after about 5 minutes, intermittently opening the application, during which audio interruptions often occur.

Here is a link to the test repository and the C code that uses the stable version of Miniaudio, but it's worth noting that even with the development version, the problem persists. Also, whether it's Aaudio or OpenSL ES, the anomaly is always present.

Also my device is a Google Pixel 5 with Android 14 and the audio recorded with my Linux computer and Audacity like if it's was my Bluetooth headset.

https://github.com/gungun974/AndroidMiniaudioGlitchOnWakeUpTest/blob/main/app/c/main.c

Here is a sample of the kind of audio anomaly I experience when my application comes out of sleep, as well as what the interruption in the sine wave looks like.

You can see here the sine wave is freeze when my Device screen wake up

audioanomalyandroid.mp4

Have you ever heard of similar problems on Android?

Is there something wrong the way I setup my Android project that can produce this anomaly?

If there anything I can do to solve this issue. I'm of course open ^^

[znakeeye]

Actually, I'm experiencing something similar. I have my Android device muted. Then, when resuming the app, there is sometimes a "pop" sound. Maybe it's called crackling, popping or clicking ...? It's like a short spike of very high volume. Not so nice!

In any case, it's easily reproducible in our app.

1. Enable Don't keep activities in Developer Options.
2. Open app and quickly exit it.
3. Repeat step 2 until you hear the click.

The key here is the Don't keep activities setting. You should try it. Does your problem occur more frequently with that setting enabled?

[gungun974]

The key here is the Don't keep activities setting. You should try it. Does your problem occur more frequently with that setting enabled?
So I just try what you said and I was maybe wrong on something else.

1. Don't keep activities don't change the frequency where the pop appear. (In fact you made me discover in my sample test project, if Android decide to recreate the activty, my app will crash since two miniaudio will be open at the same time. But this is not the audio glitch bug we are talking here).
2. The glitch seem to be completely random ! After some extra test, I got the crack while just turning off my screen and on continuously. So the bug only occurring on long sleep seem false.

Also I got in my previous test my device muted but when I unmute it, I still got those strange completely random pop on wake up.

[znakeeye]

That crash is likely fixed in #920. You might want to try it out.

[gungun974]

That crash is likely fixed in #920. You might want to try it out.

This is not the same issue. It's just in my sample test project. I never clean when the activity close miniaudio and so I constantly recreate miniaudio activity. Also for the audio bug. I also try your PR to see if your fix fix that and sadly no.

[znakeeye]

I'm wondering if it has anything to do with ma_has_default_device__aaudio().

In this function, a device is temporarily opened as "shared". I'm thinking that you may sometimes end up opening the previously opened device (owned by your process), allowing it to process some samples (silence) since you now re-opened the stream.

What happens if you simply return MA_TRUE from that function?

[gungun974]

I will try it later but I also did some extra test with the google c++ library « Oboe » and my results are very similar with the audio glitch I have.

Oboe works very similar to miniaudio since it’s also use the same Backend and got a callback function too so I reused the miniaudio sine function and same result. So it’s seem my problem is not a miniaudio bug but a miss configuration of my android app.

But that’s still not explained to me why I got those silent spike when I turn on my phone or worst. Open the quick power button camera shortcut (yes opening my camera also creates the anomaly).

I need to try now if with exoplayer I got the same issue too but I’m suspicious that I should not open my audio device in the activity but in a foreground media service.

[gungun974]

What happens if you simply return MA_TRUE from that function?

After editing the ma_has_default_device__aaudio(). Nothing happens, always the same silent issue.

[znakeeye]

I was planning to register a separate issue for the "popping" I'm observing, but I do think it's related to what's described in this bug. Here's a video showing the "pop" after 4 seconds. Note that I enabled the Don't keep activities setting (or it would take forever to reproduce).

popping.mp4

[gungun974]

I was planning to register a separate issue for the "popping" I'm observing, but I do think it's related to what's described in this bug. Here's a video showing the "pop" after 4 seconds. Note that I enabled the Don't keep activities setting (or it would take forever to reproduce).
popping.mp4

No in my very simple app I don't get a pop when opening sorry.

[gungun974]

Okay I'm running out of idea and test. At first I was thinking this was an issue with Service vs Activity but it appear that c++ thread don't follow this pattern and are behave exactly like linux thread. Than after watching the video of google "Best practices for Android Audio (Google I/O '17)" and do a tiny, it's look like my audio glitches appear when my audio callback thread is switching between core.

I try to set a thread Affinity with sched_setaffinity but I still got those glitches and my thread still move between cores. Also I try to bind the callback thread to some Foreground exclusive cores with getExclusiveCores but it appear my phone don't have such cores available -_-.

Since I tough this mind be the callback was slowdown by the change of cores, I decided to try to augment the aaudio buffers by chaning the performanceProfile and after the periodSizeInMilliseconds in ma_device_config but even when the buffer preload a large amount of data. When I switch to an other application. I still got thoses glitches.

I still don't have test if using just regular ExoPlayer with a sample wav got the same glitches behavior but this will not change the fact I don't understand why I got glitches when opening my camera app and why Spotify app for example don't have any glitches.

I should also try other android phone but for now, this story make me very tired :(

[znakeeye]

You have four layers to consider. Your phone (drivers), AAudio, miniaudio and your custom code. Let's eliminate AAudio as the source of error:

#define MA_NO_AAUDIO // Use OpenSL instead.
#include <miniaudio.h>

[gungun974]

You have four layers to consider. Your phone (drivers), AAudio, miniaudio and your custom code. Let's eliminate AAudio as the source of error:

#define MA_NO_AAUDIO // Use OpenSL instead.
#include <miniaudio.h>

Okay switching to OpenSL don't change the same "plock" behavior when I open my camera shortcut (yeah camera shortcut is so much faster to test than waiting 5 minute :/)

But I finally managed to find my old android phone ! A xiamomi mi A2 from 2018 where the last update is Android 10.
This phone look to don't have any support for AAudio but after trying directly my main application on it. (with OpenSL)
Those "plock" were not present when I open my camera shorcut.

I need to find a third device with a newer version than Android 10 and is not a potato but it's seem something is different between Android 10 et 14 🤔

[znakeeye]

Try acquiring a wake lock?
Modern Android is more aggressive when it comes to power management.

[gungun974]

Try acquiring a wake lock? Modern Android is more aggressive when it comes to power management.

Okay in my main application, I use a flutter library called audio_service where some specific android code are provided.
After looking at their AudioService.java, it's seem they already handle perfectly fine the WaveLock when starting the foreground service while I play.
Also my AndroidManifest seem good with the declaration of the Foreground service and permisions fore WaveLock and ForegroundService enabled.

[gungun974]

Okay after some more extra test with two phone from a friends with Android 14 and 15. My issue can't be reproduce on his phones. It's look there is something wrong with my phone so I will look into backup it and factory reset it to see if those issue happens on clean system.

[znakeeye]

Do you have Bluetooth enabled? Try disabling it, in case it somehow interferes with the active device.

Also, are there no clues in logcat? If you enable debug logs in miniaudio?

[gungun974]

Do you have Bluetooth enabled? Try disabling it, in case it somehow interferes with the active device.

Also, are there no clues in logcat? If you enable debug logs in miniaudio?

Sorry for the delay, like said, I completely wipe off my phone to test if when the system is clean, my issue occurred and sorry its still here.

Also like said previously, I thinks it's not an issue with miniaudio or Audio or OpenSL ES. With tests conducts on various android phone that got the same code without the issue or the basic example of Google Oboe where my issue is also present. (proof it's not Miniaudio fault).

Last, I already try to read through logcat what could go wrong on my phone but since it's not miniaudio directly. I don't know what to filter and the amount of logs is too vast and seem completely random to really identify an issue.

Oh and for the bluetooth, nope, without it I still got those glitches.

I think now I should try other application that also use miniaudio or Oboe and see if when I do the same thing, I got the same result on my phone, if it's not the case, maybe those projects can lead me the way on why I got those crack.

[gungun974]

Miniaudio is a truly remarkable project because it provides me with a unified API where I can directly feed my uncompressed audio and have my system play my sound.

It works perfectly on Linux, Windows, iOS, and MacOS. However, I've noticed some strange interruptions in sound playback on Android that I can't understand why it happens when my application comes out of background mode.

Initially, I thought that the audio artifact was due to using Flutter for my UI or due to my C++ code responsible for decoding audio with libav for Miniaudio, but after experimenting in a generic Android project with just Miniaudio, C, and a simple 220Hz sine wave, I encountered the same anomalies regardless.

For your information, I have produced an audio recording and a test project that can reproduce the anomaly.

My protocol involves launching the application, turning off my phone, and after about 5 minutes, intermittently opening the application, during which audio interruptions often occur.

Here is a link to the test repository and the C code that uses the stable version of Miniaudio, but it's worth noting that even with the development version, the problem persists. Also, whether it's Aaudio or OpenSL ES, the anomaly is always present.

Also my device is a Google Pixel 5 with Android 14 and the audio recorded with my Linux computer and Audacity like if it's was my Bluetooth headset.

https://github.com/gungun974/AndroidMiniaudioGlitchOnWakeUpTest/blob/main/app/c/main.c

Here is a sample of the kind of audio anomaly I experience when my application comes out of sleep, as well as what the interruption in the sine wave looks like.

You can see here the sine wave is freeze when my Device screen wake up
audioanomalyandroid.mp4

Have you ever heard of similar problems on Android?

Is there something wrong the way I setup my Android project that can produce this anomaly?

If there anything I can do to solve this issue. I'm of course open ^^

Well I still don't know why but this issue self solved itself by reset factoring my phone. I still don't know why I have those splock when my phone wake up but since I can't reproduce the original behavior on any device now.
I will close this issue.