Fix audio player state not becoming AudioPlayerState.IDLE when queue emptied

[puckey]

• when queue becomes empty, make player state become AudioPlayerState.IDLE (which denotes “No AudioItem is loaded and the player is doing nothing.”) instead of AudioPlayerState.ENDED which denotes Playback stopped due to the end of the queue being reached.
• change docs for AudioPlayerState.ENDED
• add test

[dcvz]

LGTM 👍 Nice catch!

[hschmied]

Am I correct, that this will change the current behavior (react-native-track-player v4.0.0-rc5) of abandoning the audio-focus?

Investigating my issue, I came across this code-portion in BaseAudioPlayer.kt ...

            if (value != field) {
                field = value
                playerEventHolder.updateAudioPlayerState(value)
                if (!playerConfig.handleAudioFocus) {
                    when (value) {
                        AudioPlayerState.IDLE,
                        AudioPlayerState.ERROR -> abandonAudioFocusIfHeld()
                        AudioPlayerState.READY -> requestAudioFocus()
                        else -> {}
                    }
                }
            }

If I understand it right, the player currently only returns focus, if either IDLE/ERROR state is set or destroy is called.... ENDED would have not abandoned the focus.

Great if that's the case and I finally have a lead to deal with my issue. Thanks :)

[hschmied]

And if I may ask -- if the player is paused/stopped, the AudioPlayerState is set to PAUSED/STOPPED and remains that or is the lifecycle to later become IDLE?

I guess if the player is playing Music/Main-Audio content, it would make sense to keep the focus, but if the player is used for 'secondary-/temporary-audio', I guess even if pause/stop is triggered, the focus should be returned.

[puckey]

@hschmied IDLE is only reached when the queue is empty

[puckey]

Am I correct, that this will change the current behavior (react-native-track-player v4.0.0-rc5) of abandoning the audio-focus?

Investigating my issue, I came across this code-portion in BaseAudioPlayer.kt ...

            if (value != field) {
                field = value
                playerEventHolder.updateAudioPlayerState(value)
                if (!playerConfig.handleAudioFocus) {
                    when (value) {
                        AudioPlayerState.IDLE,
                        AudioPlayerState.ERROR -> abandonAudioFocusIfHeld()
                        AudioPlayerState.READY -> requestAudioFocus()
                        else -> {}
                    }
                }
            }

If I understand it right, the player currently only returns focus, if either IDLE/ERROR state is set or destroy is called.... ENDED would have not abandoned the focus.

Great if that's the case and I finally have a lead to deal with my issue. Thanks :)

@hschmied I am curious – what bug were you seeing? We could add ENDED and STOPPED to the list of states where focus should be abandoned...

[hschmied]

Thank you for replying and taking the time; my issue is, that I am using rntp to queue and play spoken audio (content-type speech), intended for temporary focus only. Hence if music from another app is playing and my app requests focus, plays the short audio (maybe a second one, if queued) and when done abandon the focus, so the regular music or audio-book app can resume. (Another scenario would be that the user pauses/stops manually, in which case the focus also would have to return... but I digress).

With what I've tried so far, music playing in the background was halted, when my app triggered & played its audio, but once it was done, the music (or audiobook) from the 'other' app didn't resume. So my assumption is either my app communicated that I need the audio-focus permanent as 'music' or my app never communicated that I am releasing my audio-focus again.

I also posted on the rntp-discord, since I wasn't sure if it might be problem or just a clarification issue on my part.

[puckey]

Hmm I don't have any experience with creating temporary audio interruptions. Pull requests are welcome for something like this..