二週間のご無沙汰でした。ＳＡＬです。

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

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

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

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

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

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

二週間のご無沙汰でした。ＳＡＬです。

最近、ＰＣオーディオと言う言葉も定着してきた感がありますが、ＳＡＬが目指す方向との違いも徐々に感じられるようになりました。
どうも、ＰＣを使ったオーディオには二つの流れがあり、それらをＰＣオーディオと一つの言葉で括ってしまうことに、原因があるようです。
その二つとは、簡単に言うと「ＰＣありき」か「オーディオありき」かです。
「ＰＣありき」とは、ＰＣで音楽を聴くにしても、もっと楽しめる音にすること。
「オーディオありき」とは、従来からのオーディオソースにＰＣ音源も加えること。
と思ってください。
この二つは、将来的に合流する可能性もゼロではないかもしれませんが、少なくとも今は別の流れと考えた方が良さそうです。
ＰＣ雑誌のオーディオ記事の多くは、前者の立場で書かれたものが多いので、後者の方が読む場合は注意が必要です。
また、後者の立場での議論にも、ＰＣに対する誤解（迷信）が含まれている場合があり、こちらも要注意です。

そこで、これまでの話も含めて、ＰＣを使ったオーディオについて、何回かに分けてお話したいと思います。
先ずは、第一回目として表題の項目について述べてみます。
最終目標は、「ＰＣ音源の音質は他のアナログソースに匹敵、若しくは凌駕できるか？」に答えることです。
では、始めましょう。

「デジタルだから正確だ！」等と聞くことがあると思いますが、この主張はそれこそ正確ではありません。
有限の情報を「正確に保管する」或いは「正確に渡す」には、デジタル化は有効な手段ですが、充分ではありません。
正確さを保障するには、以下の二つが必要です。
① 誤り検出が可能であること
更に、誤り率が比較的高い場合には、
② 誤りがあった場合に、訂正若しくは再送が可能であること
です。このことをもう少し掘り下げて説明します。

① 誤り検出機能とは
実際に伝送や記録で使用されるメディア（物理媒体）は、アナログ量を利用するので、ほぼ無限とも言える情報量を保有しています。
デジタル情報は、その中から曖昧な部分を極力排除して、ほんの一部を有限な情報媒体として利用しています。
つまり、受け渡しに都合の良い部分だけを利用するので、つい正確だと思ってしまいますが、誤りが無い訳ではありません。
そこで、誤り検出を可能にする為に、本来の情報から算出される「余分（冗長）な情報」を加えます。
一番簡単な例がパリティビット(parity bit)です。
例えば、１バイト毎にパリティビットを加え９ビットを１デジットとして渡すこととします。
ここで加えた１ビットが冗長ビットになります。

偶パリティ(even parity)を例に、仕組みを簡単に述べてみます。
本来の情報は１バイト（２５６通り）なのですが、もしこの部分のＯＮのビット数が奇数の場合は、パリティビットもＯＮにします。
そうすると、正しいデータは「常にＯＮのビット数が偶数」になっている筈です。
偶然二つのビットが反転した場合も正しいと見なしますが、起こりうる確率は一つの場合の二乗程度になります。
言葉のあやですが、万に一つであれば、億に一つとなり、精度がぐっと上がります。
昔のＩＢＭ互換機のメインメモリ構成はこうなっていました。いかにも実務のＩＢＭらしいと思えます。
因みに、ホビーユースから発展してきた多くのＰＣは、パリティ無しでした。
ＩＢＭ互換機も、ＥＤＯを使う頃からはパリティ無しになってきましたが、
ＩＣ自体の信頼性向上というよりも、パリティエラー後の処理が問題だったのかもしれません。
業務用サーバ機等では、自己修復能力②のあるＥＣＣを採用して、対処しているようです。

② 訂正若しくは再送が可能とは
伝送の場合は、送り主がいる訳ですから、受け手でエラーを検出したら、再送を要求することも可能です。
こうすることで、よほどのことがない限りは、情報を正確に受け取ることができます。
欠点は、送り主が受け手や伝送経路の品質に縛られることです。（例えば、ブロードキャスト不可とか…）
別の視点で言うと、送り主が希望したテンポで送ることが保障されない点です。（リアルタイム性への障害）
例えば、皆さんが今使っている通信手順であるＴＣＰ/ＩＰを例に取ると分りやすいかもしれません。
ＴＣＰはＩＰの上位のプロトコルとしてスタックされています。
ＩＰはパケット単位の情報をネットワークを駆使して受け手に届けるための手順で、再送に関する手順はありません。
誤り訂正の為の再送プロトコルはＴＣＰの担当です。
皆さんが今使っているブラウザはこのＴＣＰの上位にあるアプリケーションなので、このブログもＷＦＰのダウンロードも正確に行えます。
逆に、ＩＰ電話が何故ＩＰなのかも、正確さよりリアルタイム性を重視する所以です。
実は、ＰＣにおける音楽再生もこの状況は同じです。（詳しくは、回を追って述べます）

データを保存する場合は、再送手段を持ちえませんので、自己修復方式がよく使われます。
折角なので、自己修復の仕組みを簡単な例で説明します。
先ほどのパリティビットに加えて、ある纏まったバイト数（仮に３２とする）単位でデータを括り、そこに一バイトのパリティデータを加えます。
冗長な一バイトは、それぞれのデータラインＤ0～Ｄ7のパリティを担当します。
（８×３２長方形の縦横方向にパリティチェックを行う）
今、５番目のバイトとＤ3がパリティエラーしていれば、５番目のＤ3ビットを反転すれば、正しいデータに戻ります。
実際にはより洗練されたチェック方式を使います。
たとえば互換機のＨＤでは、通常データは５１２バイトのセクター単位に分けられます。
これにアドレス等のヘッダ情報とお尻にＣＲＣと呼ばれるチェックデータを付けて記録されます。
このＣＲＣが、自己修復機能つきのチェックデータです。
勿論修復能力は完璧ではありませんので、駄目な場合はＣＲＣエラーとなります。
つまり、エラーなく読み込めた場合、そのデータ（例えばWAVファイル）は、書き込んだものと同一です。
万全を期すために、書き込み直後に読み出しチェックをする場合もあります。
こうすることで、書き込みエラーや不良メディアの検査になります。

今回は長話になってしまって申し訳ありません。
取り敢えず、以下のことを覚えておいてください。
「ディジタルデータは正確に伝える手段を持ち合わせていますが、
そのためにはリアルタイム性を犠牲にする場合が有りえます。」