search

sbooth / SFBAudioEngine

A powerhouse of audio functionality for macOS, iOS, and tvOS
https://sbooth.github.io/SFBAudioEngine/
MIT License
572 stars 86 forks source link

`Unnecessary _nowPlaying change` assertion failure #366

Open kunalzigma opened 1 month ago

kunalzigma commented 1 month ago

After rigorous testing for our audio requirement which is fast playback of a different sounds multiple times but individually, we see this happen.

Screenshot 2024-10-23 at 3 11 23 PM Screenshot 2024-10-23 at 3 11 30 PM

crashReport2310.pdf

Was able to recreate this, by playing audio and then check if it isplaying and pausing it in applicationWillResignActive. But now cannot recreate it again. Happens rarely like once a day in 2 hour session a day.

Screenshot 2024-10-23 at 3 39 33 PM

![Uploading Screenshot 2024-10-23 at 3.39.33 PM.png…]()

sbooth commented 1 month ago

I appreciate the report, especially on iOS as I primarily use SFBAudioEngine on macOS.

The potential good news is that this shouldn't cause any major problems in non-debug code since the assert is disabled. That being said, it shouldn't happen.

I'll need to find a way to reliably trigger the issue to debug/fix it. Since the callbacks are asynchronous it might take some work to determine a way to reproduce the problem.

kunalzigma commented 1 month ago

Thank you for the library. I have tried almost every AVAudioEngine Library for my requirements but avaudioengine always have crashes in every library. Even tried avaudioengine myself, i get even more crashes. Currently using AVAudioPlayer, though sounds are not as per my expectations but it is reliable. No crashes. Only issue with AVAudioplayer is when app is running on efficiency cores, it does not performs as intended whereas on performance cores, it is great. And as a developer, i think i cannot control which core my app is running on. Tried a lot. This library does the job for us in efficiency cores.

Thats certainly good news, if this wont crash on user's device. And will changing the play url get back to normal playback in that particular situation? Users wont mind that, i think.

sbooth commented 1 month ago

Yes, assuming that DEBUG is not defined for production (release) builds the assertion won't be present. Other than a spurious delegate callback with the same now playing value there won't be detrimental effects.