建築・設備見積りソフト、見積システムの事なら 和田特機株式会社

建設業向け 業務支援タブレットアプリシリーズ 好評発売中

和田特機株式会社HP

等時性の障害となる要因

二週間のご無沙汰でした。SALです。

前回は、「PCの音声再生は、音源データの操作を前提としてる為に、それ以降は等時性が必須!」
と話ました。WFPのように、再生のみに特化し何も操作しないアプリでも、
既存のオーディオインターフェースを使う限り、この制約から逃れることはできません。
せいぜいが、この等時性の障害(邪魔)にならないようにするしかありません。

「アプリ側の方が、スレッド実行順位は低いから大丈夫」と思ってはいけません。
ストリーミングを行うには、どうしても再生中に、HDやNICといった外部デバイスからデータを受け取り①、
それを、適当な単位でドライバに渡さ②なければなりません。
もう少し具体的に問題点を洗い出して見ましょう。

① I/O機器からのデータ取得には、ブロック転送等によるリソースの占拠期間があり、同様のI/O機器である音声装置へのアクセスに干渉します。
② アプリ側からの呼び出しにドライバ側が同期すると、実行順位の低さが等時性の足かせになります。
但し、②については、MSの資料によれば「WASAPIの導入時に改善された」ようですが、逆に言うとVista以前は確実に影響が有ったということです。
更に注意して頂きたいのは、PCフリークの言う「些細なこと」が、オーディオファイルの方にとっては「致命的」も有りうることです。

WFPは、アプリ側で一切ストリーミングを行わないことで、この問題を回避しています。
特に、Experimental では、PCMデータをメモリ上に置くことで、I/Oバスでの衝突も回避しています。
再生中のデータフローは「入力はメモリーから、出力はI/Oへ」と言う構造です。
また、等時性と言っても、若干の遅れ(Latency)を許せば、その分がゆとりになります。
一般的には評価の低いカーネルミキサーですが、ここでの遅れは意外と貴重です。
但し、レートコンバーターが働くと、データの有効桁数を大きく損ないますので、標本化周波数は必ず合わせておきます。

最後に、「私のマシンはビットパーフェクトが実証されているから大丈夫」と思っている方へ…
これまでの話で、お解りとは思いますが、ビットパーフェクトを実証する為には、ストリーミングを避けてはいけません。
何故なら、データを狂わす最大の原因がストリーミングだからです。
せめて、一曲分(五分程度)のデータをストリーミングで再生し、例えば S/PDIF 出力側で正確なテンポで正確な値を実証しなければなりません。
ストリーミングもしないような、小さなサイズのソースで行っても意味がありません。

但し、この問題を突破しても、DAC迄の等時伝送や時間精度、DACが抱える Alias による有効桁数の低下(音色の変化)が、次に控えています。

コメント