SoundFlow on Android stops playing sound after 8-10 seconds.

[Romout]

Hi,

I am working on a Metronome Application for Android. Its a .net Maui/Blazor hybrid. I am creating a WAV before starting to play for the whole measure (so, for instance, 4 beats with accents) and am playing that WAV within a async task every 4 measures - I don't use looping to be able to sync the visual metronome every measure.
When I am running the application from visual studio on my android device, it works without any issues.
However, when I start the application without visual studio, audio output stops after around 8-10 seconds but my visual metronome keeps going so the async task is still active.

I tried several things but could not yet solve my issue:

• Check that all objects are kept (i.e. no garbage collection problems)
• Properties of sound player seem ok (i.e: IsPlaying, Volume, Mute)
• Added a forground service + Permissions
• Play a permanent silent WAV in a loop

Do you have any suggestions?
Thanks anyways for your help in advance,
Ramin

[Romout]

Hi again,
After some testing, it seems to be an isolated issue on my phone, sound is working okay on other phones.
I've got Android 12 on a Xiaomi Poco X3. I guess you won't have any hint for me, right?

[LSXPrime]

Good morning,

There appears to be an issue with the miniaudio backends for Android, specifically AAudio or OpenSL ES. I'm unsure how the Debug build (with Visual Studio attached) differs from the Release build, as both SoundFlow and miniaudio binaries are built in the Release profile. This may require further investigation, primarily to determine the available backends information from miniaudio. For now, I will add this to my TODO list.

As a side note, you may want to consider attaching a log to the OnPlaybackEnd event to determine whether the library stopped playing or the sound was muted from the backend.

[Romout]

Thanks for the quick reply! I will attach the log and see what I can find out. When running it without visual studio, its still the same build, so its a debug build (I don't redeploy, I just stop the process so visual studio is detached and restart it on the phone.

[Romout]

Unfortunately, its the backend. I only receive the event in case I actively stop the playback.

[LSXPrime]

I will attend to this once I have completed the previous issues. Please accept my apologies for any potential delays that may occur, as I also still need to maintain some other repositories.

[Romout]

Thank you so much. I totally understand!

[Romout]

Sorry for coming back to you so early - I've got an interesting trace:
The difference between the good case (i.e.: Debugger from Visual Studio attached) and the bad case is the following: The garbage collector get's in the way and that sounds like a good trace. Here are catlogs to support my claim:

logcat-good-case.txt

logcat-bad-case.txt

The line of interest is in the bad-case:
02-28 20:04:58.877 14816 15112 I name.beatronom: Explicit concurrent copying GC freed 4156KB AllocSpace bytes, 9(404KB) LOS objects, 49% free, 4884KB/9769KB, paused 56us,31us total 16.621ms

As I already thought of that, everything I directly use (i.e. player, mini audio engine, my service, etc.) is held as field to prevent GC from collection. Everything using DI is setup as singleton for that reason as well.

Can you make something with that information?
Thanks!
Ramin

[Romout]

its just a lead as I couldn't reproduce that which makes me sad.

[Romout]

I've got something and I think that settles my issue completely. When building/deploying with visual studio, the app will only work correctly with studio attached. If I run the deployed app later again, it stops the sound after a few seconds.
How ever, if I generate a signed release build and install it manually or via google play-stores internal testing to my device, it works (I just didn't see that as I always tested afterwards with the visual studio deployed build) and thats exactly the reason for it to work for my friends on their devices.

So: I think we are pretty good, I will continue to try to fully understand what's the difference between the two cases but that's my job to do and not yours.

Thank you so much for your help and time!
Keep up the cool work!
Ramin

[LSXPrime]

Good to see you tackled it. While we found an issue on macOS and iOS regarding signing, which I hope was solved now by adjusting the signing process in the native library build, there were no specific instructions for signing on Android builds. Maybe it's an Android safety mechanism to unload the unsigned binaries or mark them as unsafe, and the developer must sign them with Google Play. I will investigate later if anything can be done to the signature in the build process.

[Romout]

Yeah, Sounds like that. There is no obvious setting so it's most likely a protection or something. Ahmed Abdallah ***@***.***> schrieb am So., 2. März 2025, 11:39:

…

Good to see you tackled it. While we found an issue on macOS and iOS regarding signing, which I hope was solved now by adjusting the signing process in the native library build, there were no specific instructions for signing on Android builds. Maybe it's an Android safety mechanism to unload the unsigned binaries or mark them as unsafe, and the developer must sign them with Google Play. I will investigate later if anything can be done to the signature in the build process. — Reply to this email directly, view it on GitHub <#8 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDBLHF27ZU7XL4A3S3GRAL2SLNWJAVCNFSM6AAAAABX7HDW5KVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMZWGUYDQNQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>