react-native-track-player icon indicating copy to clipboard operation
react-native-track-player copied to clipboard

iOS: FLAC audio playback desynchronizes when using seekTo

Open gyc-12 opened this issue 1 year ago • 4 comments

Describe the Bug When playing a song in FLAC format on iOS and using the seekTo function to jump to a specific position, such as 100 seconds, the actual sound played does not match the sound at the 100-second mark of the song. This discrepancy causes the lyrics to be out of sync. This issue seems to occur especially when manually skipping to near the end of the song at the beginning, or advancing from near the end, the issue can be reproduced. In contrast, there are no such problems with 128k or 320k music formats.

Steps To Reproduce It seems like there is an issue with playing FLAC format songs on iOS, especially when manually skipping to near the end of the song at the beginning, or advancing from near the end, the issue can be reproduced.

Code To Reproduce await seekTo(time)

Replicable on Example App? I have successfully reproduced this issue in the example. After multiple large jumps forward and backward, the audio at 1:19 no longer matches what is played by the local player. image

Environment Info: Paste the results of npx react-native info npx react-native info

WARNING: You should run npx react-native@latest to ensure you're always using the most current version of the CLI. NPX has cached version (0.73.6) != current release (0.75.4)

info Fetching system and libraries information... (node:2357) [DEP0040] DeprecationWarning: The punycode module is deprecated. Please use a userland alternative instead. (Use node --trace-deprecation ... to show where the warning was created) System: OS: macOS 14.4.1 CPU: (8) x64 12th Gen Intel(R) Core(TM) i3-12100F Memory: 39.21 MB / 16.00 GB Shell: version: "5.9" path: /bin/zsh Binaries: Node: version: 22.5.1 path: /usr/local/bin/node Yarn: version: 1.22.22 path: /usr/local/bin/yarn npm: version: 10.8.3 path: /usr/local/bin/npm Watchman: version: 2024.07.15.00 path: /usr/local/bin/watchman Managers: CocoaPods: version: 1.15.2 path: /usr/local/bin/pod SDKs: iOS SDK: Platforms: - DriverKit 23.2 - iOS 17.2 - macOS 14.2 - tvOS 17.2 - watchOS 10.2 Android SDK: Not Found IDEs: Android Studio: Not Found Xcode: version: 15.1/15C65 path: /usr/bin/xcodebuild Languages: Java: version: 17.0.8 path: /usr/bin/javac Ruby: version: 2.6.10 path: /usr/bin/ruby npmPackages: "@react-native-community/cli": Not Found react: installed: 18.2.0 wanted: 18.2.0 react-native: installed: 0.73.6 wanted: 0.73.6 react-native-macos: Not Found npmGlobalPackages: "react-native": Not Found Android: hermesEnabled: Not found newArchEnabled: Not found iOS: hermesEnabled: true newArchEnabled: false

info React Native v0.75.4 is now available (your project is running on v0.73.6). info Changelog: https://github.com/facebook/react-native/releases/tag/v0.75.4 info Diff: https://react-native-community.github.io/upgrade-helper/?from=0.75.4 info For more info, check out "https://reactnative.dev/docs/upgrading?os=macos". Paste the exact react-native-track-player version you are using v4.1.1 Real device? Or simulator? simulator and device What OS are you running? ios

How I can Help What can you do to help resolve this? Have you investigated the underlying JS or Swift/Android code causing this bug? Can you create a Pull Request with a fix? This is my test music. 2.flac.zip

gyc-12 avatar Oct 08 '24 11:10 gyc-12

full disclosure im not an ios person. do u mean the useProgress event emitted will eventually not track the correct progress?

could u reproduce with native so we r clear if this is an RN limitation or what. u might wanna ask the native community instead if so.

also anecdotally i know flac are much slower to load. so im not surprised if things are slow to respond. however i doubt the progress event emitted degrades, unless its calculated instead of directly read by AVPlayer.

lovegaoshi avatar Oct 08 '24 22:10 lovegaoshi

full disclosure im not an ios person. do u mean the useProgress event emitted will eventually not track the correct progress?

could u reproduce with native so we r clear if this is an RN limitation or what. u might wanna ask the native community instead if so.

also anecdotally i know flac are much slower to load. so im not surprised if things are slow to respond. however i doubt the progress event emitted degrades, unless its calculated instead of directly read by AVPlayer.

大佬应该是个中文开发者吧,我猜测您的apm在ios上应该也有此问题,我的英文并不好,请允许我用中文描述下问题。就是经过大跨度的seekto快进或者快退之后,虽然useprogress返回的position和seekto的目的地的确是一个地方,但是实际播放出来的声音却不是这个position该播放的声音,而是其他位置的声音,这导致歌词与音频不再匹配。主要问题就是快进快退后歌词不同步的问题很苦恼。😮‍💨 This is a fast-forward or fast-back over a large span. Although the position returned by useprogress and the seekto destination are one place, the actual sound played is not the sound to be played at that position, but at another location. This causes the lyrics to no longer match the audio.The main problem is that the lyrics don't sync after fast forward and backwards.

gyc-12 avatar Oct 09 '24 06:10 gyc-12

我是果黑 不用ios 因为不知道是RN机能限制 RN asset打包 配置 还是原生的问题 请你尝试在原生上复现 这个库只能解决RN的问题

lovegaoshi avatar Oct 09 '24 16:10 lovegaoshi

我是果黑 不用ios 因为不知道是RN机能限制 RN asset打包 配置 还是原生的问题 请你尝试在原生上复现 这个库只能解决RN的问题

感谢您的回复,我理解了,我会尝试在原生上复现问题 Thanks for your reply. I understand. I will try to reproduce the problem natively

gyc-12 avatar Oct 10 '24 01:10 gyc-12

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days.

github-actions[bot] avatar Jan 08 '25 02:01 github-actions[bot]

This issue was closed because it has been stalled for 7 days with no activity.

github-actions[bot] avatar Jan 16 '25 02:01 github-actions[bot]