A/D変換によりデジタル化されたデジタルオーディオ信号の伝送に関しては、民生用ではS/PDIF（SONYとPhilipsにより規格が提案されたのでS/P Digital InterFace）、業務用ではAESが標準化されています。したがって、現実的には私たちはS/PDIFを使用せざるを得ません。実はHDMIのオーディオパケットもS/PDIFと同じですので、この機会に勉強しておくのもよいと思います。今回はS/PDIFことについて勉強する前に、デジタル信号の伝送の基礎知識について紹介しておきます。
デジタル信号の伝送そのものに関しては、デジタル化された信号がオーディオであるのか、文字データであるのか数値データであるのか、内容とは無関係にとにかく高速で間違いがなく伝送することが要求されます。これの要求に応え、高速かつ正確な伝送を実現するために、これまで何十年にも渡って、無数のエンジニア達が知恵を絞ってきました。そのような努力と知恵の成果がコンピュータの世界だけではなく、S/PDIFを含めたデジタルオーディオの伝送についても活かされています。
一番最初のデジタル信号の伝送は「モールス符号」です。昔、短波放送などのBCLやアマチュア無線に興味を持たれていた方はご存知と思いますが、アルファベットやカナ文字を「トン」と「ツー」の組合せで、送受信していました。最初は2本の電線の間に電流を流し、電流ループのOn-OFFあるいは強弱（0の場合は電線が切れていると判断できるように）により、受信側のリレー（継電器）や回路を操作していました。「ツー」は「トン」の3倍の長さ、「トン」や「ツー」の間隔は「トン」1ヶ分、文字と文字の間隔は「トン」3ヶ分、文と文の間隔は「トン」7ヶ分というように決められています。電気信号以外では光（ライトの点滅）でも、モールス信号を伝送することができます。
これを図-1のように「トン」を短い長円、「ツー」をその3倍の長さの長円として並べてみると、なにやら見たことのあるものに見えます。
|
図-1 CDのpitはモールス信号に似ている。 |
CDの記録パターンです。CDでは"0"を意味する短円のPit（「トン」）、"1"を意味する長円のPit（「ツー」）が渦巻線上に配置されています。実際のCDでは、読み出しヘッドの位置が少しくらいずれても正確に読み出せるように、Pit（凹部）の幅や長さ、深さ、配置などが工夫されているだけではなく、CD作成時には元のデジタル化された音楽データ（LPCM 16bit/44.1kHz）を、読み出しエラーが発生しにくくかつ修復しやすいように特別なアルゴリズムを使用して、ビット列に変換した後、誤り訂正のための符号化と並べ替え、さらに、情報の単位ごとにフレーム化が行われ、実際のPitが配置されています。
音楽をマイクロホンで拾った後、A/Dコンバータでデジタル信号したオーディオ信号は基本的にはI2S（最近ではSACDと同じ1bitのDSDが使用されることもあるようですが）ですから、本Blogの#20（I2S編）でも述べたように3bit（3本の信号線）が必要です。音楽CDの制作の際には、まずこれを「トン・ツー」の組合せが1列にならんだ1bitのビット列にする必要があります。1回のサンプリング分のLch.,Rch.それぞれ16bitのbit列を8bitx4のbit列にします。その各4byteのbit列を6組（サンプリング6回分）をまとめ、誤り検出・訂正のためにリードソロモンという方式でCIRC符号化します。CIRC符号化によって元の24byteのbit列は32byte（256bit）に拡張されます。その後、サブコード（CDの先頭やトラック先頭からの位置情報（経過時間情報）などのアドレス情報）の8bitが先頭に追加され、全体がEFM（8/14。8bitのbit列が14bitに拡張される）方式で変調されます。EFM変調により拡張された各14bitのbit列の間には3bitの結合bitが挿入されるので、全体が（3+14）+（（3+14）x32）の561bitに拡張されます。さらに、サブコードの先頭部には同期用として24bitのプリアンブルと3bitの結合bitが追加され、全体で588bitの長さのフレームが形成され、実際のpitの配置が決まります。
CD上のこのフレームを読み出した後、エラーがあればこのリードソロモン符号が数学的に処理され、元の正しいbit列が復元されます。そういうことならば、CDから読み出した生データのbit列の訂正処理を行った後、TOSLINKのカプラ（送信モジュール）や他の送信回路を駆動させて、デジタルオーディオ信号を伝送すればよいではないかという疑問は湧いてきますが、CD上のbit列やフレームはCDに特化されていますので、デジタルオーディオ信号を幅広く伝送するには力不足です。そこで、S/PDIFが登場し、LPCMだけでなくDolby AC-3やDTSなどの圧縮データも取り扱えるように規格化されたわけです。
S/DPIFはご存知のように信号線としては1本（GND-Returnを含めれば2本ですが）で、電気的には片側がGNDレベル（固定電位）のシングルエンド（アンバランス）信号です。Software的（論理的）には1bitのDigital信号ということになります。1本の信号線上にbit列をシリアル（直列）に乗せて伝送するシリアル通信はコンピュータやデータ通信の世界では常識で、私たちも創業以来25年間、すいぶん「痛い目」に会わされてきました。特にHigh-Speedシリアル（LAN 10Mbps, 100Mbps,1Gbps,IEE1394/i-link（400MBps）, USB2.0（480Mbps）,SATA （3Gbps）にはプリント基板の設計を含めて、ずいぶん苦労しました。おかげで測定器類も揃えざるをえず、測定技術も習得せざるをえませんでしたので、HDMIの信号品質テストなどは軽くPassすることができる実力が備わりました。先にも述べましたが、HDMIのオーディオ信号の伝送はS/PDIFの規格に準じて行われています。したがって、HDMIをマスターするためにも、S/PDIFおよびシリアルデータ伝送に関して"通"になっておくことは必要と思います。
モールス信号に続くシリアルデータ伝送の原始的なものはASYNC（非同期）通信方式です。これはモールス信号のように、トン・ツーの可変長の組合せだけでは、途中で切断されたりしても分からず、エラーチェックもないため、データ伝送をより高速化・効率化されるために考え出された方式で、図-2のようにスタートbitとストップbitでデータの基本単位（文字）を区切り、パリティチェックを設けるという方式です。
|
送信側、受信側それぞれがStart bitを基準に一定のClock（間隔）で信号の論理を判定する。 図-2 ASYNC（非同期調歩）通信方式 |
TELEXやテレタイプなどで標準的に使用され、コンピュータの世界でも端末機とのインターフェイスになくてはならないものでした。今でも、マイコン組込み機器の開発時やコンピュータの故障診断時などで重宝されています。最近では19.2kbpsなどの速度が当たり前ですが、当初は110bpsが主流で、その後300bps,1200bpsなどが主流でした。おわかりのように、この速度ではとてもオーディオデータは送れませんので音声信号は同じ電話回線を使用してアナログで伝送されていました。これをさらに高速化し、エラーチェックをフレーム（情報の単位）ごとでも行えるようにしたのが、同期（SYNC）通信と呼ばれる方式です。
|
データ列の前後を同期確定用のSYNCコード（01001100）で囲む。また一定時間ごとにSYNCを挿入して同期がずれないようにする。FCS（Frame Check Sequence）はCRCチェックなどのError検出情報。 |
図-3 同期(キャラクタ同期)通信のフォーマット |
個々の文字情報に相当する部分からスタートbitとストップbit、パリティbitを取り去り、高速化に対応するとともに、フレームごとにCRCチェックを行うようになりました。このままではどこがフレームの先頭で、どこが終端かわからないので、先頭にSYNCパターンと呼ばれる特別なbit列をくっつけて、受信側でそれを検出して同期を取り、終端にも同じようなパターンを追加しています。S/PDIFでも、後ほど説明しますがこのSYNCパターンと同様に、プリアンブルと呼ばれる同期のためのbit列が各フレームを構成する2個のサブフレームの先頭に付加されています。このあたりの話は、S/PDIFがいかにデジタルオーディオ伝送用として考え出されたかというバックグラウンドの知識としてお読みください。
注）実際の電話回線上はこれらの直流信号がそのまま伝送されているわけではなく、モデムや音響カプラで音声帯域の信号に変換されて伝送されています。誤解のないように続きをお読みください。
同期通信は銀行のオンラインなどで標準的に使用されましたが、速度が2400bps、4800bpsなどで増大するデータ量を高速に誤りなく伝送するという要求にはついてゆけなくなっていました。また、伝送されるのがデータのみで、それをサンプリングさせるクロックは伝送されていないため、送信側、受信側の両端でクロックを同期させるのが難しく、高速で大量のデータを伝送することができませんでした。そのため、モデムのような交流信号としてではなく、直流信号のままでクロックとデータを重ね合わせる（データの中にクロックを埋め込む）ということを中心にしたいろんな通信方式が提案されては消え、また新しい物が提案されて...という状況でしたが、25年くらい前にXroxなどからEtherNetという通信方式、通信プロトコル、Networkが提案されました。それがIEEE802.3として標準化され、今日ではパソコンのLANとして当たり前になっています。現在のLANの物理層は100Base-Tと呼ばれる電話線のようなツイストケーブル（撚り線）の2ペアが使用されていますが、25年くらい前はイエローケーブルと呼ばれる直径が15mmくらいの太くて固いシールドケーブルでした。そのケーブルにMAUと呼ばれるboxを噛み付かせ（ケーブルの途中に金属製の歯で噛み付かせて外部のビニール被覆を突き破りシールドに接触させ、さらにその中心部に針のようなもの突き刺して中心にある芯線に接触させるという強烈な方式でした）、MAUとパソコン（増設インターフェイスボード）との間は、これまた太い15芯のケーブルで接続するという代物でした。
電気信号の面では、10Mbpsでデジタル信号を伝送するために、bit列そのままでは"0"が連続した場合や、"1"が連続した場合にデータの判別が難しくなるので先に述べたCDのpit配置と同様にbit列に変調をかけていました。CDの場合はEFM変調とCIRCでしたが、EtherNetの場合はManchester Code（Phase Encoding）と呼ばれる方式でした。この方式は図-4のように、一本の信号線にクロックとデータを重畳させて伝送することができます。
|
図-4 ClockとDataをエンコードしてひとつの信号にする（LAN IEEE802.3の例） |
I2SのSCLKとデータ（SD）も、同じようなエンコード処理を行えば同軸ケーブルや光ケーブル（単方向）で伝送できそうな気がしますね。このManchester Codeは更に改良されて8B/10B EncodingやPhase-Sift Keying（FSK）などに発展しましたが、S/PDIFでは採用されていません。S/PDIFは別のBiphase Mark Codeと呼ばれる方式（詳細は次回に説明します）が採用され、I2SのSCLKとSDataが別の方法で重畳（SCLKが埋め込まれて）されて1bitの信号になるように変調されています。
EherNetはその後、10Base2（10Mbpsでケーブル長が2mまで）という規格が制定され、ケーブルが3C2Vと同じ太さの同軸ケーブル＋BNCコネクタとなり、ずいぶん使いやすくなりました。ただし、インピーダンスはTVのアンテナ用やS/PDIF用の同軸ケーブルと違って50Ωでした。当然、ボード上の送受信回路とのインターフェイスはトランス結合でアイソレーションされていました。しかし、ターミネータの位置やボード上でのFrame-GND、Signal-GNDの処理などで通信エラーが頻発し、抑え込むのにずい分苦労をしました。そのため、現在もあまり同軸ケーブルは使いたくありません。S/PDIFの場合、Ethernetに比べて周波数が低い（4Mbps以下）ので扱いやすいという利点はありますが、やはり両端でのインピーダンスマッチングやGND（同軸ケーブルのシールド側）の処理などをきちんとしないと、データ化けやGNDからの高周波ノイズの回り込みなどで苦労させられます。市販の製品のS/PDIF同軸入出力部を見ると、抵抗1丁でターミネイションしているだけで、基板上の信号線パターンのインピーダンスコントロールも行われておらず、とても簡略化されています。本来は同軸ケーブルよりも、GNDの分離という面では光（TOSLINK）の方が有利ですが、S/PDIFで使用されているTOSLINKカプラやプラスチックファイバの帯域幅が狭いという問題があります。これを解決するために、一部のAudio機器では「ST-Link」という名称でLANの10base-F対応の送受信モジュールや、コネクタ（カプラ）、光ファイバを採用していたようです。これなら10Mbpsが保証されていますので、サンプリング周波数を96kHzに上げても伝送可能でしたが、工場内LAN用として耐ノイズ性を売りにした10Base-Fがさっぱり普及せず（低価格の10Base-Tの性能が上がったので）、送受信モジュールやコネクタ、光ファイバが生産中止になってしまい、「ST-Link」も消滅（?）した感があります。
IEEE1394（i-Link）やUSBのIsochrounous転送を含め、オーディオの世界はエラーがあっても再送や訂正のためのプロトコルが定められておらず、「聴き流す」だけが一般的なようです。 データ通信技術をずっと追いかけてきて、「録音時にA/D変換されたデジタルデータを正しくDACに伝える」ということをモットーとしている私たちから見るとちょっと困ったことです。
次回はS/PDIFのエンコード（Biphase Mark Code）から、話を進めてゆきたいと思います。
またまた、ご教示いただけますれば幸甚です。
Windows XP, Vistaなどのusbaudio.sysの標準ドライバはUSBのIsochronous転送を使用しており、その場合エラー検出時の再送は一切ないという理解でよろしいでしょうか？
一方、御社の製品ではusbaudio.sysを使用せずに独自のドライバで受信機との間で送達確認を行い、エラー検出時には等時性確保の範囲内で再送を試みているという理解で正しいでしょうか？
投稿情報: Bunpei | 2008年11 月20日 (木) 23:24