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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

現在は、Hybrid2S が何故良い近似を与えるのか、数理に基づく解析を試みていますが、あまり芳しくありません。
フィルタの透過範囲(-fs/2～fs/2)を僅かに狭め、その差分周波数を微小パラメータにとると興味深い係数が現れたりしますが、まだまだ五里霧中といった段階です。

話は変わりますが、１月１２日の東京出張の帰りに、Ｋ’ｓさんが買った某技術系の雑誌を見せてもらいました。
理由は、「ＵＳＢデバイスをターゲットにしたＰＣオーディオ特集」が組まれていたからです。
良かったらＳＡＬも買おうかと思ったのですが、ＤＡＣの説明部分を読んで萎えてしまいました。

理由は、説明に使っていた変換対象のデジタルデータが、標本点間で１しか違っていなかったためです。
念のために言っておきますが、(1bit)ＤＳＤの説明ではありません！
確かに、動作原理は簡潔さを求められるので、「方便！」のつもりかもしれませんが、
次のステップ（標本点）までに、１単位（分解能ぎりぎり）しか変化しないのでは、繋ぎ方は完全にネグられます。
結果、オーディオソースとしての未解決問題を見過ごしてしまいます。

実際ＣＤのＰＣＭデータは、数千つまり３～４桁のオーダーで変化します。
１６ビットでこれですから２４ビットなら６桁の変化は当たり前です。
サンプリング周波数を４倍にしても、１桁も下がりません。（１０倍でやっと一桁です）

お好みのソースがどれくらいか知りたければ、Gradient.exe が提供する MaxGradient の値が参考になります。
但し表現は３２ビット１６進表記ですから、１６ビット換算する場合は、下二桁を無視してください。
例えば、0x00635d79 ならば、635d を関数電卓で１０進表示で見てください。
結果は、驚きの 25437 です。（最近のＣＤでは、おとなしい方かも）
場合によっては、符号付１６ビットの最大値 32767 を超える場合もありえます。
（最大傾きは、原理的に最大振幅のπ(≒3.14)倍までありえます。）
但し、この値は瞬間最大値であり、隣までの平均値でもないので、仮に半分の 12718 にしても４桁を超えています。
くどいようですが、次の標本点までの変化を１としたのでは、途中のアナログ値のでたらめさを隠蔽してしまうのです。
（上記のデータの最大変化量を１にしたかったら標本化周波数を更に25437倍しなければなりません）

ＳＡＬは、新聞なども含めて書籍の信頼度を測るのに、自分の得意分野の説明や論理を参考にします。
明らかな間違いや、単なる言葉の遊びに終始しているものは論外です。（意外と多い）
そうではなくても、以下のようなことには注意が必要です。
“複雑な現実をそのまま扱うことは不可能なので、通常は本質ではないと思われるファクタを取り除きなるべく単純化します。
このモデル化が、嘘（間違い）か方便（適切）かは、自己無矛盾性とネグった影響の大きさが試金石になります。”

先の例では、最大振幅が 11025 の入力を仮定した場合、ゼロからその値に到達するのに少なくとも 11025 標本点を要します。
此処までで1/4周期ですから、一周期に必要な標本点は 44100 個となり、サンプリング周波数が 44.1KHz なら、１秒の周期になります。
最早、「音」ですらありません。

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

年明け第一回目の「ヘッドホンアンプ考」の最後で「-12dB のバーゲイン」と表現しましたが、これはパワーアンプの増幅率（電圧比率）への補正を表わしたものです。
本文の論旨からいけば、電力回路の減衰器なので、単体での電力伝達率として表現すべきでした。
その場合は、負荷インピーダンスに依存しますので、
取り敢えず、６４Ωで近似すると、更に -9dB 食われ、大体 -21dB ぐらいです。
８ΩＳＰドライブに対して、ミュートＳＷ入り(-20dB)程度と思っていただければ結構かと思います。

話は変わりますが、最近頂いたお便りの中に「ＣＰＵを替えると待ち時間の改善ができますか？」といった旨のものが有りました。
Ｐ４４及びリサンプリングは、倍精度浮動小数点演算を多用するので、かなり時間を食いますが、逆に言えば演算能力による影響も大です。
（Ｐ４０は傾きチャンクを利用することで、残りの計算時間はＰ２１～Ｐ３６と同程度になります。）
実際どの程度の依存性があるかを見る為に、「ＣＤデータを、192KHz にリサンプリングする」場合の待ち時間を測定しました。
また、内蔵の傾き算出時間は、Matrix24 を使った値です。
使ったＣＰＵは、①Core i7(920:7.4/7.4)、②Core2 Quad(Q9400:7.2/7.2)、③PentiumD(945:5.1/5.3) の三つです。
ＯＳは何れも Windows7 で、カッコ内のコロン以降の数値は、ＣＰＵとメモリーの評価サブスコアです。
楽曲ファイルの長さは、14:13(853sec.) です。
また、初回は実際のメディアからの読み出し時間という不確定な要素が追加されるので、二回目以降にしました。
（精度の悪い測定法ですが、複数回で同じ結果でした）

結果（時計を使った目視計測なので、秒単位です）
① 傾きチャンク１秒：傾き算出なら９秒：リサンプリング２２秒
② 傾きチャンク１秒：傾き算出なら１２秒：リサンプリング３４秒
③ 傾きチャンク１秒：傾き算出なら２０秒：リサンプリング５２秒

「改善」と言うからには半分以下にならなければなりません。
③→① であれば、５３秒が２３秒（傾きチャンク無しで、７２→３１）なので、
「効果有り」としても良さそうですが、③が現役の可能性は低いと思います。
但し、①も今となっては古々タイプなので、最新ＣＰＵならば結構良い値が期待できそうです。

WFP4Exp側もマルチコアを生かしていないので、その為だけでＣＰＵを替えることはお勧めできません。
もし買い換える場合には、実際のパフォーマンスを比較してから決めると良いでしょう。
（もし Atom 系からの変更であれば、効果は絶大ですが…）

結論：
当然、効果は有ります。
しかしながら、コストに見合っているかは、総ての面でケースバイケースでしょう。

今日は、ＳＡＬです。
お正月に楽曲ファイルを整理していて、以前報告した不具合の「読み出し」版に遭遇しましたので、対応できるように修正しました。
今回は、読み出し側なので、WFP4Exp gradient BindWavs Hybrid2S の四つが該当します。
古いＯＳ（Ver.5.2以前）でファイルサーバを利用する場合は、更新してください。

これとは別に「一時間半ほど連続再生していると音が途切れるようになる」と言う不具合報告が有ったので、
複数のＰＣで、２４時間耐久レースじゃなかったテストを行いましたが、症状は現れませんでした。
ＳＡＬの記憶では、ＵＳＢデバイス用の標準ドライバを使った時に、似たような症状を経験しています。

WFP4Exp は、アプリ側でジッタを増やさないよう、ドライバを通常とは違った風に使っています。
従って、それに耐えられないドライバがあるのかもしれません。
報告された症状は、あたかもＭＳ得意のガーベージコレクションが働いているようにも見えます。
（再生中にやっちゃいけないことですがね…）
WFP4Exp再起動（プロセスを一度ごわさんにする）で対処できることなら、対策法も有りそうなのですが、
「ＯＳリブートが必要」となると、残念ながらアプリ側では対処不可能と考えます。
（WFP4Exp は、再生中はメモリアロケーションどころか、ＵＩのイベント処理以外何も行いません）