winapi - IDirectSoundBuffer Lock，为什么要通过 2 个部分？

Question

在 IDirectSoundBuffer8 的 lock 方法上，我们假设传递 2 个部分及其各自的大小。那些是什么？第一部分是开始，第二部分是锁的结束？它们与主要和次要缓冲区有关吗？立体声？我完全迷路了。

有人可以帮忙吗？

Answer 1

最好的答案是:除非您使用的是 Windows XP，否则不要使用 DirectSound。

如果你一次只播放一个声音并且你不关心任何实时混音，你可以使用像 PlaySound 这样简单的东西。 .我假设您实际上想要实时混音和播放多个重叠声音的能力。

对于 Windows 8、Windows 8.1 或 Windows 10，您可以使用操作系统中内置的 XAudio 2.8 或 2.9。否则，您可以使用 XAudio 2.7，它是 legacy DirectX SDK 的一部分。 .

见 Learning XAudio2一些教育资源。

见 DirectX Tool Kit for Audio用于 XAudio2 的简单 C++ 包装器。

回复:DirectSound 缓冲区

对于您最初的问题:在 Windows 95 的旧时代，“主缓冲区”是提交给硬件的实际音频缓冲区。 “辅助缓冲区”是您创建个人“声音”以一次播放多个声音的地方。然后系统将所有辅助缓冲区混合到主缓冲区中进行播放。

然而，自从过渡到 NT 之后，“主缓冲区”就不再存在了。有一种叫做“主要”缓冲区的东西，但它主要用于 BackCompat。 DirectSound 将所有缓冲区混合成一个缓冲区，然后馈送到系统进行播放。在 Windows Vista 或更高版本上，它被馈送到 Windows Core API (WASAPI)，它在实际到达音频硬件之前混合来自系统和所有正在运行的应用程序的所有声音。

You can use WASAPI directly, but the API is quite restrictive because it doesn't do any application-level mixing or source-rate conversions. Generally you only use WASAPI directly if you are an audio engine that has already done all the required conversions and mixing and just want to play a final mix.

无论如何，处理 Lock时有两组指针的原因是因为它是一个“环形缓冲区”，又名“循环缓冲区”。在 Windows 95 的旧时代，部分主缓冲区实际上将由硬件在您可以在当前播放之前写入缓冲区的同时播放。你有这个复杂的两指针设置以避免覆盖仍在播放的数据——否则你会在你的声音播放中得到可怕的“爆裂”或“故障”。由于这在现代版本的 Windows 上再也不会发生，所以 BackCompat w.r.t.到主缓冲区。也就是说，DirectSound 混音器仍然利用辅助缓冲区是“环形缓冲区”这一事实，因此如果您碰巧正在更​​新播放，则在您“提前”写入时使用相同的机制来保护实时混音器读取缓冲。如果二级缓冲区没有播放，您可以安全地通过 nullptr对于第二个指针和大小。

这种老式的“环形缓冲区”模型使用起来很复杂，并且在系统内存非常有限时更为重要。几乎所有现代声音 API 都是基于“数据包”的，而不是每个播放语音都有一个待处理缓冲区队列，您可以通过向队列提交新缓冲区来添加更多数据以进行处理。您可以在缓冲区完成时收到通知，以了解该“数据包”中的音频已被处理。

此外，在 DirectSound 中，您必须将音频数据复制到 Lock 提供的内存中。 ，但现代基于“数据包”的 API 通过直接从应用程序内存中读取源数据来避免额外的副本。这确实增加了您需要确保源内存在所有播放停止之前仍然可用的复杂性(即，当实时混音器仍在读取内存时，您不能 free 内存，否则您的应用程序将崩溃)，但是作为返回，您可以避免大量额外的复制。