I have a long list of ClippingAudioSource. (about 10 hours in duration)
but the problem is that playing or pausing AudioPlayer , takes about 5 Seconds.
I have been test it for short list of ClippingAudioSource and it was Good.
but for long list I have no idea about it.
I use it with audioService.
Hi @mohammadne can you please complete the bug report in full? I do not know what platform you're testing on and what type of audio files you're using in your example, whether the audio files are local or remote or assets, etc. etc. so it would be impossible for me to investigate this or give you some insights as to what's happening.
I am test it in debug mode on android pixel 2.
the audio file type in ClippingAudioSource is AudioSource.uri(Uri.parse(path)),
the audio files are remote.
I don't face any exception in terminal to report it here but there is a noticeable delay in playing long files.
(I meant is it an mp3 file type or something else?)
It naturally takes time to perform a seek on remote files because it takes time to download them. Additionally, depending on the type of audio, seek efficiency can vary. So for optimal performance you would need a good audio format and a local file.
Hi @ryanheise
sorry for misunderstanding, the files are mp3.
Do you meant that in mp3 files , we download the whole file or only download the file until buffered position ?
mp3 files are known to have an issue with seeking since the header typically doesn't contain a sufficient index of what byte position to jump to for each time position. At least on Android, what you may find is that the seek on a local file can still be fast, but it won't be accurate. If you use aac/m4a instead, you will have both fast and accurate seeking. In all cases, local files will be faster than remote files.
If the file is remote, seeking within the downloaded part (up to buffered position) will be as fast as local.
Hi @mohammadne assuming I have answered your question, I will close this issue. Remember in future issues to also fill in the issue template exactly because I will soon be implementing some workflow rules to automatically check this.