Mac OS X 上的 OpenAL:设置 AL_SAMPLE_OFFSET 不起作用
在工作中,我们无法使用 alSourcePause()
来暂停声音,并且在任何情况下我们可能希望以偏移量开始声音。
我们通过使用 alGetSourcei()alSourcei(this->sourceId, AL_SAMPLE_OFFSET, this->sampleOffset);
来执行“恢复”代码>.我们尝试使用 AL_SEC_OFFSET
、AL_BYTE_OFFSET
和 AL_SAMPLE_OFFSET
- 但没有成功。我们已经了解到,声源需要处于“初始”状态;重新创建源并附加缓冲区,然后尝试跳过也没有帮助。
更改缓冲区以跳过 AL_BYTE_OFFSET
并不是解决方案,因为它会使循环变得复杂。
流媒体声音在速度较慢的机器上会跳跃;我们在实现多线程播放时遇到了麻烦。
由于我们的日程安排很紧,那么在 OS X 上的 OpenAL 上跳过简单声源的一部分的最佳方法是什么?
源代码位于我们的 Sourceforge 存储库。
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.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我最近在 OS X (10.6.8) 上的游戏引擎中遇到了同样的问题。当恢复播放具有给定样本偏移量的静态缓冲区时,我们按以下顺序执行了以下步骤:
源在此之前停止,并且所有缓冲区均未排队。根据 AL 1.1 规范,应该可以
(请参阅官方规范的第 4.3.2 节,网址为 http://connect。 Creativelabs.com/openal/Documentation/OpenAL%201.1%20Specification.htm )
在我们的例子中,反转上述序列中的后两个调用(即在发出 alSourcePlay() 调用后设置缓冲区偏移量)就达到了目的。从技术上讲,这应该是一种完全有效的方法;但是,如果音频线程在这两个调用之间中断时间过长,则可能会导致可听到的故障。
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:
The source was stopped before that, and all buffers were unqueued. According to the AL 1.1 specs, it should be possible to either
(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.