[sdlsound] Sound_seek()?

[Ryan C. Gordon]

> ...should we add a Sound_seek() function? My thought is that decoders can
> optimize this is possible, and if not, the library can attempt to decode
> and throw away to a given point if seeking forward, or try rewind()ing
> followed by decoding to a given point if seeking back.

To clarify my own post:

  Unlike Sound_rewind(), there is more involved in seeking than just
having a RWops that can seek, and thus, some decoders may find it
hard/impossible to seek accurately or at all, but (assuming Sound_Rewind()
works) we can always fake it by decoding from the stream and just
throwing the decoded contents away until we get to the byte position
we want...this can be a potentially huge performance cost, and I'm
inclined to have such drivers report a failure to the application, which
should fully expect such a possibility.

It is also possible that we can put some of those bits we're using for
Sound_Sample->flags to use. Once the user calls Sound_NewSample(), they
could check a hypothetical flag:

  (returnedSample->flags & SOUND_SAMPLEFLAG_CANSEEK)

Or something.

Again, let me know if this is completely retarded.

--ryan.