前提: RTF < 1
sr = n (step/sec)
#
AR: i sec/forward (step)
前提より i < 1/n
streaming_io_latency_ar = forward = i
i (<1/n)
NAR: j sec/forward (batch)
b step/batch => n/b batch/sec
前提より j < b/n
NARはbufferingと切り捨てが可能.
このとき
0<= buffer step <= b
0 <= t_buffer sec/buffer <= b/n
streaming_io_latency_nar = forward + buffer
= j + t_buffer
buffer=0が最速
ただし追加制約として
j < b/n が j < に厳格化
(b-buffer)+1倍 (ちょっと違う)
bufferingすると1/n <= t_buffer
ゆえに
latency > 1/n
ARのRTFより必ずARが低遅延
bufferingなしの場合
j < 1/nを前提として i vs j
普通NARの方がモデルデカいので不利
no buffering
i vs j
NARは
Streaming IO latency
語句導入
Streaming IO latency: input-output latency of stream
inputが時間を伴って入ってきて、そこから処理して出力するまでの遅延
バッチ処理をしようとするとbufferingが必要になり、このlatencyが伸びることになる.
わりと制約の大きいlatency
低遅延リアルタイム処理はstreaming IO latencyでよく評価できそう.
声質変換にはいくつかの用途がある.
変換音声の「返し/モニター」を前提にすると低遅延リアルタイム処理が要件にあがる.
c.f.
返しをしない場合の方がシチュエーションとしては多い.
YouTubeとかでライブストリーミングしようとしたら嫌でも数秒遅延するし（映像こみで）バッファリングもかけるため、50msecバッチとかで処理していっても何ら問題がない.
また、Discordで会話みたいなシチュエーションは悩ましいところがある.
c.f. 電話越しの遅延
短いバッチで処理してもいけそうだけど、みたいな微妙なライン.
