Querying AL_PROCESSED_BUFFERS

[minghia]

When you call alSourceQueueBuffers to queue the audio but don't call alSourcePlay, a call to alGetSourceI(src, AL_BUFFERS_PROCESSED, &processed) returns the number of items queued not the number processed. I'm not sure how 1.25.2 does this calculation but 1.24.2 and 1.23.1 assign Current without checking whether or not Current is nullptr.

ase AL_BUFFERS_PROCESSED: CheckSize(1); if(Source->Looping || Source->SourceType != AL_STREAMING) { /* Buffers on a looping source are in a perpetual state of PENDING, * so don't report any as PROCESSED */ values[0] = 0; } else { int played{0}; if(Source->state != AL_INITIAL) { const VoiceBufferItem *Current{nullptr}; if(Voice *voice{GetSourceVoice(Source, Context)}) Current = voice->mCurrentBuffer.load(std::memory_order_relaxed); for(auto &item : Source->mQueue) { if(&item == Current) // If nothing has played Current is nullptr and this loop returns the number of items in mQueue break; ++played; } } values[0] = played; } return true;

I have a bug in my code where I'm not calling alSourcePlay but if processed is set to non-zero value. Anything queued is indicated as being processed when it hasn't.

[kcat]

If the source is in a AL_STOPPED state, all buffers are considered processed and AL_BUFFERS_PROCESSED will be equal to AL_BUFFERS_QUEUED. Since the currently active buffer is used and updated by the mixer voice, which is managed asynchronously in a real-time thread that can't be blocked, and a stopped source does not have a mixer voice, as it's not playing anything and leaves it to other sources that may be playing, that means the source itself doesn't really know how many buffers have played. It only knows when it can query the mixing voice for the buffer it's currently on.

Instead, the idea is that a source in a AL_STOPPED state is one that was just playing and either stopped naturally at the end of the queue (or had alSourceStop called), where all buffers have finished. This could be because the stream is finished (when there's no more input) or because it underrun (if there is more input and it wasn't able to be queued in time for some reason). In both cases, you can clear out the buffer queue and "reset" the source state (call alSourceRewind which puts it into an AL_INITIAL state; all other user-controlled properties like AL_POSITION, AL_GAIN, etc, are left alone).

In an AL_INITIAL state, no buffers are considered processed and AL_BUFFERS_PROCESSED will always be 0 regardless of AL_BUFFERS_QUEUED. With that, you can either start a new stream (if the last one finished), or keep filling and queueing from the current stream (if it underrun), and start the source again as desired.