search

kcat / alure

Alure is a utility library for OpenAL, providing a C++ API and managing common tasks that include file loading, caching, and streaming
zlib License
70 stars 20 forks source link

Sample offset should be set only after attaching source to buffer? #24

Closed LAGonauta closed 6 years ago

LAGonauta commented 6 years ago

I noticed sources that I set the offset were not being played starting at the offset I selected, so I did some investigation. It seems that Alure sets AL_SAMPLE_OFFSET correctly with OpenAL Soft, but not with Creative's and Rapture3D's drivers.

This function works in those drivers only if AL_SAMPLE_OFFSET is set to a source that has a buffer attached, not before attaching the buffer. I coded a workaround in Alure just by setting the offset on line 386 (play()) on source.cpp right before playing the source, and shifting mOffset = 0 after the function. The function checkPending() may also need to be modified.

It seems that the specification says nothing about the correct order of operation, is that right? For now I will be using the workaround, but I am sure it can be made prettier. I can do a proper PR if desired.

Thanks.

kcat commented 6 years ago

It seems that the specification says nothing about the correct order of operation, is that right?

Hmm. The spec says, about the AL_*_OFFSET properties:

When setting AL_..._OFFSET on a source which is already playing, the playback will jump to the new offset unless the new offset is out of range, in which case an AL_INVALID_VALUE error is set. If the source is not playing, then the offset will be applied on the next alSourcePlay call.

with no mention of a buffer. Neither the AL_BUFFER property or alSourceQueueBuffers mentions anything about the offset. So the only logical conclusion is OpenAL Soft's behavior: if the source is not playing, the offset is stored and applied later on a successful alSourcePlay[v] call, irrespective of what happens with the source's buffers in the intermediary. Interestingly, OpenAL Soft's behavior was inherited by Creative's Generic Software driver (the last LGPL version they released, anyway), so it's a bit odd that you see different behavior in Creative's drivers. But yeah, absent any spec updates clarifying the behavior, I'd say it's a bug with Creative and Rapture3D.

That being said, it shouldn't be a big deal to work around the problem in Alure. No sense leaving broken behavior with those drivers if it's not a burden to make work another way.