ericoporto
commented
1 year ago I don't know if this is testable in some way, but if you want to experiment, Android and Emscripten ports don't use mojoAl, they use their own platforms al implementations - I could set those up for mojoAl, but the Emscripten implementation was really good when I tested because it leverages what's on the Browser, and the Android one was just a surprise it existed, so I let it use it. I think these two also have things like HRTF, that is not in mojoAl.
I confirmed at least the Emscripten port doesn't have the limitation you mentioned.
I've been told that the OpenAL specification requires all buffers in the queue to be of same length; see this conversation.
Currently OpenAlSource class does not impose such restriction. This does not lead to any serious errors with mojoAL, as it seems to not care, but there's a small glitch with "jumping" position between two looping playback iterations.
In practice the usual case for lesser buffer is the end of the playback. We could fill the remaining space with silence. The situation becomes bit more complicated as the input data may be looped. I guess, OpenAlSource could wait until the next buffer is fully filled with data before queueing it. But it has to detect somehow if it should wait or not.
Implementation notes
The buffer size may be assigned by the first input buffer, as in most common case these will be sent equal, until before the end of the input data.
The biggest problem seems to be BufferRecords: right now there's strictly one record per Al's buffer, but with this change there will be no direct relevance between them. This means (among other things), that a playback timestamp may change in the middle of the openal's buffer. Likely BufferRecords will have to be updated at the GetPosMs and Unqueue, counting played time. This will let us know which BufferRecord corresponds to the openal's playback now.