Re: PING: Queueing fails for buffers with streamed sources

On Monday 21 May 2007 03:28:57 pm you wrote:
> Also, what would happen if it wants 99,564
> bytes for the next frame and you only give it 98,765?

It could either generate an error, or empty the buffer and report 0 bytes. 
Generally a frame is pretty small though.

> Still, after thinking about it, this might be the most straightforward
> mechanism.

It is kinda straight forward, and I could see apps making simple use of it. 
But unless the spec for the extension explicitly indicates such behavior, an 
app can't rely on AL_SIZE being anything meaningful beyond the stored buffer 
size (and even that can be a generalized, given how the SI deinterleaves and 
duplicates the audio data pointers). It could've been unexpectedly converted 
or decompressed, too.

> Ah.  That makes SAMPLE_OFFSET make sense at least, but it also implies
> that the data would need to be decompressed before you could handle it.
> You'd at least need to have some way of calculating the correct offset
> in the compressed stream to the corresponding uncompressed sample.

If it's decoded on the fly, you just keep track on the number of samples 
decoded. Seeking to a byte offset would more than likely place the read 
cursor at the nearest/next keyframe (to ensure error free decoding). Seeking 
to a sample offset in a compressed stream would be a trick, though.

But still, I think I'm favoring on-load decode-to-pcm. Real-time decoding 
means that the data would need to be decoded + converted + split, only to 
filtered then re-interleaved and mixed into the device's buffer. What's fun 
is that libvorbis gets the data as deinterleaved itself, so it'd have to be 
docoded, interleaved, converted, deinterleaved, filtered, then reinterleaved 
again. Not something you should be doing in mixer processing, IMO.