There were a few race conditions in the multithreaded code in RNAudioRecorderPlayer.swift.
self.recordTimer is set from the main thread. If caller invokes startRecoder and then subsequently stopRecorder, there is no guarantee that self.recordTimer will be set in time. This will result in "ghost" rn-recordback events being sent to the React Native thread.
To resolve this, this PR creates the timers on the react-native bridge thread, and then manually adds them to the main thread's run loop.
self.audioRecorder has a similar issue. It's created on the main thread, but then stopPlayer checks its value on the bridge thread. To resolve the race condition here, this PR dispatches the check on the main thread
There were a few race conditions in the multithreaded code in RNAudioRecorderPlayer.swift.
self.recordTimeris set from the main thread. If caller invokesstartRecoderand then subsequentlystopRecorder, there is no guarantee thatself.recordTimerwill be set in time. This will result in "ghost" rn-recordback events being sent to the React Native thread.To resolve this, this PR creates the timers on the react-native bridge thread, and then manually adds them to the main thread's run loop.
self.audioRecorderhas a similar issue. It's created on the main thread, but thenstopPlayerchecks its value on the bridge thread. To resolve the race condition here, this PR dispatches the check on the main thread