HcaAudioStream doesn't seem to be seekable about deretore HOT 5 OPEN

Ah, the fact that EnsureSoundDataDecoded etc taking position as an argument itself shouldn't be a problem - the problem is, in my humble opinion, it should iterate through every block from the beginning to the current position, rather than every block from the current position to the end (of loop).

from deretore.

On the other hand, I think in a common streaming scenario, it should assume that the beginning part, rather than the following/ending part, is available.

from deretore.

Hmm... Maybe making HcaAudioStream seekable isn't as challenging as I thought. However, anyway, because of the fact that every block depends on the state decided by its prior block to be correctly decoded, the beginning part still has to be (in the first place: available - and then) decoded in order, only after that could the decoder then hand out decoded WAV PCM data.

from deretore.

Hmm... As for:

in a common streaming scenario, it should assume that the beginning part, rather than the following/ending part, is available

I think even if, like, the user drags the timeline/progress bar to skip some part in the beginning, (strictly saying) the decode still has no choice but to download & decode all prior blocks in spite of the fact that those block will probably never be used/played.

(However, according to my rough observation, the "effect" won't last for more than 1 block, so maybe fetching & decoding 2 prior blocks (rather than the whole part up to the beginning) is already enough)

from deretore.

Ah, after skimming VGAudio's related code (related: Nyagamon/HCADecoder#4 ), I think maybe (still not very sure) this "state/context" dependence problem shouldn't be as important as I originally thought.

from deretore.