react-native-track-player: [iOS][1.1.4] App freezes when buffering a new track

Note This only occurs on the latest 1.1.4, 1.1.3 and below don’t have this performance issue.

Problem

When playing an unbuffered track the app will completely freeze until the required buffering to play the app is completed. The UI thread will drop to close to 0, however no action can be taken (scroll, navigating, pressing anything) until the buffing is finished. This causes a dramatic performance issue whenever playing an audio.

By playing an unbuffered track I’m referring to these two scenarios:

1. Add N tracks on app load, then skip to one that is not the first. or
2. Reset the track player and add new tracks on some press handler in the app.

Video

react-native-track-player @ 1.1.4

You’ll notice in this video it looks as if I’m pressing and holding the TouchableOpacity. That is not what’s going on here, I’m just tapping it and it is freezing on it until the audio has finished buffered and then it is going back to what its doing. Same happens for any UI changes such as scrolling on a list.

react-native-track-player @ 1.1.3

Repro

I created a simplified repro here

The steps to repro are download the app:

git clone https://github.com/CapitanRedBeard/react-native-track-player-audio-bug-1.1.4.git
cd react-native-track-player-audio-bug-1.1.4
yarn
react-native link
yarn start

This will start the small repro demo with react-native-track-player @ 1.1.4 After playing with this remove the app, switch the version to 1.1.3 and restart the demo

You should notice that the TouchableOpacity buttons to play the audio no longer lag while the audio is buffing

Note This repro is extremely simplified, is a real use case scenario I would just queue up all those audio and use the skip API to navigate to the proper audio which I do in my app when I can. However there are a lot of places and scenarios where you simply need to reset the player and load up a new queue (Almost everywhere in my app in fact). So while this repro doesn’t show the best use case of the library it is used to illustrate the bug that was introduced somewhere between 1.1.3 and 1.1.4. Also you can notice this bug in this very simple repro, but in a larger project with redux the problem is a lot more noticeable and the delay can be upwards of 2 seconds. The delay completely disallows the user from doing anything. For example is a scroll list you can’t even scroll.

Possible Causes

I know that there was a lot of buffer work going on which I love but it seems that the audio and the frame rates don’t pick up until the audio has finished buffering (I assume this because I print out when we’re buffering and you see it clearly in 1.1.3 but not really in 1.1.4).