HcaAudioStream doesn't seem to be seekable

[segfault-bilibili]

I'm not majored in IT-related subjects. I'm not sure whether I misunderstand something for now, however I think something is (potentially) wrong.

The HCA (2.0, CBR?) decoding process seems to be "stateful" to me. Each block is not decoded "independently", let alone "disorderly". Every block relies on the state (decided/affected by its prior block) to be correctly decoded.

Currently EnsureSoundDataDecoded/EnsureSoundDataDecodedWithLoops takes position (in the name of waveDataOffset) as an argument - so what would happen if the stream got seeked? I haven't thought about this thoroughly, but I doubt whether the current code could correctly handle this.

[segfault-bilibili]

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).

[segfault-bilibili]

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.

[segfault-bilibili]

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.

[segfault-bilibili]

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)

[segfault-bilibili]

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.