Ryan C. Gordon
icculus at clutteredmind.org
Wed Apr 17 01:54:45 EDT 2002
> ...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)
Again, let me know if this is completely retarded.
More information about the sdlsound