iOS: FLAC audio playback desynchronizes when using seekTo
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.
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
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.
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.
我是果黑 不用ios 因为不知道是RN机能限制 RN asset打包 配置 还是原生的问题 请你尝试在原生上复现 这个库只能解决RN的问题
我是果黑 不用ios 因为不知道是RN机能限制 RN asset打包 配置 还是原生的问题 请你尝试在原生上复现 这个库只能解决RN的问题
感谢您的回复,我理解了,我会尝试在原生上复现问题 Thanks for your reply. I understand. I will try to reproduce the problem natively
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.
This issue was closed because it has been stalled for 7 days with no activity.