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

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

和田特機株式会社HP

多時間系と等時性

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

前回は、「ディジタルデータを正確に扱うことと、リアルタイム性が両立できない場合がある。」
と話ました。では、一般のPCはどちらを優先させているのでしょうか?

勿論、前者であることは、改めて言うまでもありません。
通常のコンピュータ処理に於いて、「決められた時間間隔で次々と答えを出す」と言った作業は有りません。
寧ろ、「正確であることを満足すれば、早ければ早いほど宜しい」のです。
抽象的な言い方をすれば、それぞれの任務はそれぞれの時間で行っても構わないのです。
「3時までに報告書を提出しなさい!」と命令されることはあっても、
「結果は、正確に3時から1ページ3秒間隔で、提出しなさい。」何て言う上司はいません。
通常の業務では、PC内のプロセス達は、独自の時間で処理を行えば良いのです。
そもそも、PCが提供するリソースはプロセスの数に比べて圧倒的に少ないわけですから、本当の意味で同時進行はできません。
つまり、各々のプロセスは、実時間に対してギクシャクした時間配分の中で、進行しているわけです。
このことは、OSから与えられた仮想空間(memory,I/O)と同様に、仮想時間をイメージすると判り易いかもしれません。
即ち、OSは個々のプロセスに、必要な仮想空間と共に仮想時間を与えると解釈し、全体を多時間系と見做すことにします。

逆に後者の典型は、制御用のコンピュータです。
制御用のコンピュータでは、刻々と変化する状況を捉え、実時間でコマンド処理を行わなければなりません。
言うなれば、一連の処理を総て一つの時計の下に進めなければなりません。
これを、等時処理或いは等時性(Isochronous)と呼びます。
例えば、具合の悪いデータがあるので、「この処理は後回しにする(時間分岐)」なんて訳には行きません。
平時に機能している組織が、緊急時に役に立たなくなるのは、一般の多時間的組織では等時処理ができない為です。
勿論、精度の悪いデータで制御する訳にはいきませんので、
必要な精度を保てるような、ハードウェアとリアルタイムカーネルを必要とします。

80年代、SALは多軸サーボシステムのコントロールソフト開発をメインに仕事をしていました。
当時のPCは、貧弱で当然ながらその様な用途には向いていませんでした。
しかしながら、ユーザの要望で使わざるを得ない場合は、必要なハードウェアの追加や改造を施すと共に、
総てのソフトウェアを自前で用意したものです。(内蔵LSIの初期化にBIOSを利用したことはありましたが…)
あれから20数年、PCは多大な進化を遂げましたが、リアルタイム処理が前提の機器ではありません。
しかしながら、ゲームやDVDビデオの再生等に使用されることも前提なので、希望の光はあります。

準備が整ったので、PCでの音楽プレイヤーに潜む問題を洗い出してみましょう。
今回は、DACチップ自体の問題は問わないので、正確なアナログ出力をする理想のDACを前提にします。
信号の伝播経路を大雑把に、
①WAVファイル→②プレイヤーソフト→③デバイスドライバ→④サウンド装置側のコントローラ→⑤DACチップ→⑥アナログ出力
とします。(途中LAN、USB、DDCを介する場合もあるかもしれませんが、そこに潜む固有の問題は別の機会にします)
勿論、①~④の平均処理速度は、⑤が要求するレートを充分上回っていなければなりません。
重要なのは、PC側①②③が多時間系なのに対して、⑤DACは完全な等時処理であることです。
では、この切り替えはどのステージで行うのが理想的でしょうか?
SALが提唱するような、楽曲再生の為だけならば、④サウンド装置側のコントローラの内部で行うのが理想的です。
そうすることで、何時でも正確なデータを⑤DACに必要なテンポで送り出すことができます。

ところで、この変換を行うためには、仮想時間系のギクシャクした時間を緩和するためのバッファ(空気室の様なもの)が必要です。
その容量は、与えられた仮想時間がもつ最大ギャップ(沈黙時間)を保障できなければなりません。
結果的に言えば、少なくともその程度の遅れ(Latency)は覚悟しなければなりません。
ところが、プレイヤーソフトに色々なエフェクターや表示当を付ける場合は、
その操作に関与したプロセス以降を等時処理しなければ、⑥アナログ出力と時間的なずれを生じてしまいます。
百歩譲っても、感覚的に違和感のない程度の遅れに留めなければなりません。
しかしながら、PC側のどのプロセス①②③も本来多時間系なので、遅れ縮小には限界があります。
つまり、仮想時間のばらつき以下にすれば、それだけでデータを正確に伝送できなくなります。
また、ばらつきを少なくしようと、該当プロセスの実行順位を無理やり上げても、今度は安定した動作が保障できなくなります。

コメント