koobas.hobune.stream
Streaming and Decompress On Load music type playback time difference.
Good day to you all. I encountered a problem when developing a rhythm game. I am loading music with this code:
IEnumerator GetTrack (string path)
{
request = UnityWebRequestMultimedia.GetAudioClip( "file:///" + @path, AudioType.MPEG );
((DownloadHandlerAudioClip)request.downloadHandler).streamAudio = true;
((DownloadHandlerAudioClip)request.downloadHandler).compressed = false;
yield return request.SendWebRequest();
if( request.isNetworkError )
{
Debug.Log("Not loaded");
Debug.Log(request.error);
}
else
{
//AudioPlayer.clip = DownloadHandlerAudioClip.GetContent(request);
AudioPlayer.clip = ((DownloadHandlerAudioClip)request.downloadHandler).audioClip;
}
AudioPlayer.Play();
}
As you can see, I load the track in streamAudio mode, which saves me from a long program lag, but it brings an extremely strange problem. Let's say I assign a track time of 15 seconds, 30 seconds, and 60 seconds. If the track is not streamAudio or Сompressed, nothing strange happens, but if it is, the further you move through the time of the track, the more its sound shifts become apparent. That is, 60 seconds of streamAudio is not the same place as 60 seconds of a normal loaded track. If you do not assign Clip.time and the track will just play itself, then no problems occur, no shifts are not observed. What can this be connected to and is there any way to prevent this?
P.S. - I had an idea to calculate the shift factor, but since it is not a constant value, I don't even know how to do it, except at random or by elimination. Also, the length of the track does not vary, regardless of whether the track is streamAudio.
I found a possible solution, which is to use AudioPlayer.timeSamples to move more precisely within the track. The documentation says that "Be aware that: On a compressed audio track position does not necessary reflect the actual time in the track Compressed audio is represented as a set of so-called packets. The length of a packet depends on the compression settings and can quite often be 2-3 seconds per packet. See Also: timeSamples variable."
The problem has not been solved, there is still a shift.
