关于发声延迟的原因

在Atom运行库中播放音频时，如果满足以下条件，则从播放请求到发声的延迟为最小。
（ 执行::criAtomExPlayer_Start函数后，在第一个Server处理中向平台特定的音频库发出发声请求。）

1. 内存播放
2. 不发生Voice的抢占
3. 不使用渐变器
4. 输出到本地声音渲染器

如果不满足上述1.～4.的条件，将会发生以下延迟。

关于上述1.

流播放的情况下，执行:: criAtomExPlayer_Start函数之后，在读取文件某一定程度后开始发声。
（延迟播放，直到加载开始播放所需的数据量。）

特别在执行搜索播放时，由于要执行读取文件头⇒分析文件头并计算搜索位置⇒读取搜索位置的数据…的流程，因此可能要在播放开始前等待很长时间。

关于上述2.

如果发生Voice抢占，则要执行停止正在播放的Voice⇒播放下一个声音…的流程，因此将增加发声前的延迟。
特别是如果要停止的Voice正在执行流播放，则要等待文件加载完成，有可能会等待很长时间。

关于上述3.

如果使用渐变器，由于需要在Atom运行库中执行淡入声音和淡出声音的同步处理，开始发声前额外需要1V的时间。

关于上述4.

输出到本地声音渲染器时，将已解码的PCM数据传递给平台特定的音频库，同时发出播放请求。

另一方面，使用ASR时，通过软件混音解码结果，放入正在播放的声音缓冲区。
（在此时写入音频缓冲区的数据全部播放后，播放新写入的数据。）
因此，会发生音频缓冲区大小的延迟。

注意

在Atom运行库中执行WASAPI输出时，必须使用ASR。
（因为WASAPI没有采样率转换和混音功能，所以必须由ASR代行这些处理。）

如何减少发声延迟

为了减少发声之前的延迟，必须尽可能满足上述1.～4.的条件。
至于其他减少发声延迟的方法如下。

减小音频缓冲区大小（※仅在使用ASR时有效）

在PC版Atom运行库中，可以使用::criAtom_SetAudioClientBufferDuration_WASAPI函数更改音频缓冲区的大小。
（由于按照硬件的最差性能进行了调整，预设状态下具有4V的缓冲区。）

注意

如果过度减小混音缓冲区的大小，可能会发生声音中断。
适当的大小取决于所使用的硬件，因此在通用PC的应用程序中调整此参数时，建议允许用户通过选项设置等重新设置。
（街机游戏等使用的硬件已经确定时，只需针对目标设备进行调整即可。）

缩短Server处理间隔

Atom运行库按照初始化时指定的Server处理间隔唤醒线程并执行处理。
因此即使在上述1.～4.的条件相同的情况下，Server处理间隔越短则发声延迟越小。

例如以30Hz执行Server处理时，发声请求本身在受理之前最多可能需要33.3ms。
另一方面，以120Hz执行Server处理时，即使以相同时间发出发声请求，请求会在8.3ms以内被受理。

注意

由于Server处理的动作周期取决于计时器的精度、同时运行的线程的优先级等，因此在Server处理间隔内不一定会受理发声请求。
此外，提高Server处理频率将缩短发声前的延迟，但与Server处理驱动相关的开销将增加，因此Atom运行库本身的处理负荷会增加。

补充

以上描述仅包括“Atom运行库中发生的延迟”。
除上述之外，物理发声延迟还包括平台特定的音频库中的延迟和播放设备的延迟。