Search code examples
macosopenal

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 with 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.

Solution

  • 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

    1. 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
    2. 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.