OpenAL on Mac OS X: Setting AL_SAMPLE_OFFSET does nothing
at work, we're unable to use alSourcePause()
to pause sounds, and in any case we might want to start the sound wit开发者_如何学编程h an offset.
We're performing a "resume" by doing alSourcei(this->sourceId, AL_SAMPLE_OFFSET, this->sampleOffset);
with a sample offset that we retrieved with alGetSourcei()
. We tried using AL_SEC_OFFSET
, AL_BYTE_OFFSET
and AL_SAMPLE_OFFSET
-- to no avail. We have read that the sound source needs to be in the "initial" state; recreating the source and attaching the buffer, then attempting to skip also did not help.
Changing the buffer to skip AL_BYTE_OFFSET
is not a solution, since it complicates looping.
Streaming sounds are skipping on slower machines; we're having trouble implementing multithreaded playing.
Since we're on a tight schedule, what is the best way to skip a portion of a simple sound source on OpenAL on OS X?
Source code is available at our Sourceforge repository.
I recently encountered the same problem in our game engine on OS X (10.6.8). We performed the following steps when resuming playback of a static buffer with a given sample offset, in this order:
alSourceQueueBuffers(mSourceId, 1, mBufferId);
alSourcei(mSourceId, AL_SAMPLE_OFFSET, mSampleOffset);
alSourcePlay(mSourceId);
The source was stopped before that, and all buffers were unqueued. According to the AL 1.1 specs, it should be possible to either
- specify the buffer offset when the source is in the stopped state; here, the offset is supposed to be applied upon the next alSourcePlay() call, or
- specify the offset on an already playing source, which should result in an immediate skip to the desired position.
(See section 4.3.2 of the official specs at http://connect.creativelabs.com/openal/Documentation/OpenAL%201.1%20Specification.htm )
Reversing the latter two calls in the above sequence (i.e. setting the buffer offset after issuing the alSourcePlay() call) did the trick in our case. Technically, this should be a perfectly valid way to go; however, if the audio thread gets interrupted right between these two calls for too long a time, this could possibly result in hearable glitches.
精彩评论