DTM 制作におけるデジタルオーディオ課題の本質

世の中には普通に間違っている知識が蔓延っています。

これは仕方がない部分があります。難しい話を理解できないからフワッとした話で一般的に解釈が簡単な曖昧な情報で説明説明されるからです。あとはマーケティングの数字のために事実関係を無視した解説がされることが往々にしてあります。

DTM、とりわけ、プロオーディオでもその感覚的なフワッとした情報が溢れているため、権威主義といいますか、あの人が言っていることだから間違いない、というのはよくあることで、他の界隈、特に調査会社とかシンクタンクのレポートなどで、内容に間違いがあって、それが元で事実上の存在を受けた側が訴えても、権威があるので握りつぶされる、なんて言うことはリアルな法廷闘争なのでも頻繁に起こっています。

オーディオの世界では別にそこが問題だとはあまり思いません。誰を信じるか、はその人の自由で、なにか直接的な損害を受けることはあまりないからです。ただし、権威ある人が嘘をバラ撒くのは、職業倫理的に良くない、とは思います。

さて、そんな中、現代の DTM に必要不可欠なのが オーディオインターフェイス です。これがなくても音楽制作はできます。ただし、幅は広がらない、という事実があります。アナログの最たるものである、マイク録音が行えない場合が殆どですし、アナログのオーディオ信号をスピーカーなどに送りたい、などの場合には必須になります。

USB という通信規格

現在のオーディオインターフェイスは、特に特筆がなければ、USB 接続となります。

ただし、ここには大きな問題が現代に出現しています。

USB-C という (コネクタ) 規格

現代では新しい電源コンセントの規格としても世界的に統一できる、USB-C (USB Type-C) というものが登場しています。2019 年に USB4 が発表されて、採用されている機器が発売されています。

USB4 では 48V までの容量電圧と 5A までの容量電流が使用可能ですので、最大 240W までの製品を駆動することができます。これは電圧 ✕ 電流＝ (消費) 電力です。

一般的な消費電力の少ない電化製品は動かすことができると思います。いずれ、新しい USB 規格、または USB-C のコンセントがそこら中に普及する未来が見えてきます。まだ課題も問題も多いと思いますが。

ちなみに USB-C 給電は製品本体側が USB-C の給電側 (電源アダプタ) に「これだけ電力頂戴」って命令して、電源側が「いいよ〜」って言って電力が供給されます。ですから容量が大きいアダプタを電力消費が少ないデバイスで使っても利用できます。逆では電力不足で動かないことや、バッテリーへの充電が遅い原因になります。

このコントローラーの制御が安く簡単に普及できるようになればそこら中に USB-C コネクタのコンセントが増えるとは思います。

USB Type-C は規格の名前じゃなくてコネクタの形状の名前

ここでややこしいのが USB-C という名前。USB-C はあくまでコネクタの形状の名前であって、通信規格の名前ではない。

通信規格は 2025 年現在、USB 4 Version 2.0 までが制定されています。これは 2022年の発表です。

問題なのは『コネクタの形状だけでは通信規格の内容はわからない』という部分です。

ですから「USB-C の製品だから最新の通信規格を扱える」とはならないのが問題です。そして USB4 は Thunderbolt 3 を基盤とする通信規格のため、Thunderbolt 3 と USB4 は互換性があります。そして Thunderbolt 4 と USB4 も便宜上、下位互換性があります。

ただし、Thunderbolt 3 と USB4 は同じではありませんし、もちろん、Thunderbolt 4 と USB4 は同じではありません。しょうがないけど、ややこしいね。これは USB4 が汎用規格なので Thunderbolt 3 や 4 の規格を満たしていなくても USB4 は名乗れる、という表記上の規定が違う、というものです。

表記の規定の問題でややこしくなるってことね。

ですから『USB-C の製品だから Thunderbolt 接続と同等なんだね！』っていう話は通用しないと言うことですし『このオーディオインターフェイス製品は USB-C の製品だから通信速度が早いデバイスなんだ！』なんていうことは 全く無い ということです。

まず、ここを抑えましょう。

コネクタの形状が USB-C であっても通信規格は分かりづらい

この規格の取り回しさ故に複雑化してしまったのが USB-C のコネクタの問題です。

USB-C というのはあくまで同じ電源コンセントの形状を使いましょう、って感じの話で、電圧は実はバラバラだよ、っていう現状のコンセントではあり得ない事が起きてしまった。

今の電源コンセントの場合、電圧や最大容量が形状で決まっていて、日本だと 100V コンセントと 200V コンセントではそもそもコネクタの形状が違うので絶対に 100V 製品を 200V コンセントに挿入することはできない仕様になっています。その逆も同じですね。これは安全面で非常に有用です。

ただし、コンセント側で『こいつは 200V 製品だから 200V を送電するぞ』なんていうことを把握して送電はできませんが、USB-C 給電の場合はそれに似たようなことが事実上できるということです。安全面をクリアできれば何でも刺さるコンセントのほうがいいよね。

こういう対比的な仕様があるのですが、だけど USB-C の場合だとユーザー側は「このコンセントが 200V も 100V も両方対応しているか」を把握しなくてはいけない話になってくる。つまりどこまで行ってもユーザーはちゃんと仕様を確認して使うことを求められます。

でもね、一般の方が USB や Thunderbolt の規格云々で揉めることはあまりないと思うの。仕事で使うものだったら把握しようね、って話でただ趣味で使うものだとハードルはグンと上がるよねっていう、そういう話で規格統一というものは非常に難しいんですよね。超えなければいけない技術的なハードルも多い。

Thunderbolt、PCIe 接続軸でいろんな製品を考えてほしいと思うけど USB の汎用規格も非常に素晴らしいのでなかなか難しい話です。中身を理解すると、統一できない理由には納得はできます。

Computer Audio は USB 2.0 が基本

市場には Thunderbolt 接続の USB-C 端子 と USB2.0 接続の USB-B 端子 の 2 つが採用されたデバイスがあります。下図の一番左端上の四角い USB 端子は送り側の端子規格になっていて Computer 側に USB-B 端子が採用されることは無い。

私が使っている Orion Studio Synergy Core なんかはそうですね。

Thunderbolt 3 の接続と USB 2.0 の接続を選べるが USB を選択する意味は実はある

これは DTM 初心者が買うべきデバイスではないので、例外ですが、Thunderbolt 接続と USB 接続ではそもそも端子を分けて間違えないようにしています。

まだ、明確な USB / Thunderbolt 接続端子兼用のオーディオデバイスはおそらく発売されていませんが、世の中には結構ややこしい製品を売っているメーカーもあります。これはオーディオデバイスメーカーではなく、映像関連の Blackmagic Design 社が出している業務用の機材なのですが…

同じ USB-C 端子を採用しつつ、Thunderbolt と USB 接続で異なる 2 つの端子を用意している。もちろん、こいつは業務機だから「これ買ったからには使うヤツはわかるな？」的な設計思想が見える。これは一般向け製品だと作りづらいだろうね。

上図のデバイスは USB 2.0 規格ではなく、USB-C 3.1 Gen 1 デバイスですが、私は USB 3.0 以上の規格で USB-C 端子を採用しているオーディオデバイスにはまだ会ったことがない。あったら教えてください。実物触ったこと無いから正確なことはわからないけど、Thunderbolt 端子は USB と互換性があるので間違えて接続しても認識動作はしそうだけど。

一般向けにこういう異なる規格の同じ端子を採用した製品を出すと、ユーザーの環境、状況によっては「接続したのに使えない、返金を要求する！」というクレーマーにあふれるのは想像に固くない。マジでこんな消費者しかいないのが日本だからさ。

でも今後は USB / Thunderbolt 端子兼用のデバイスが増えるとは思うけど…どうだろなぁ。

何故 USB 2.0 が基本だと言い切れるの？

そうだ、理由を話さなければ、ただの意見だ。

ここでは事実というか規格の話をして行こう。

USB Audio Class 2.0 ドライバ (UAC 2.0)

これを知らない人は結構いるかもしれないが

クラスコンプライアント (CC) モード

という言葉は聞いたことがある人がいると思う。Windows や macOS に指定のオーディオデバイスドライバをインストールしなくても OS 側のドライバで動作する、ということです。

OS にはこの USB Audio Class 2.0 ドライバ が標準でインストールされており、これに対応しているデバイスであれば、ただ単に PC / Mac と USB 2.0 で接続するだけで製品が利用できます。

Windows では usbaudio.sys (UAC1.0) / usbaudio2.sys (UAC2.0) が標準で、macOS では AppleUSBAudio.kext が標準インストールされている。

これは非常に便利です。いわゆる プラグアンドプレイ というやつで、電源いれて USB 接続すれば基本使えるってやつです。最近のバスパワー駆動デバイスであれば電源すら不必要。これは比較的安価なデバイスで USB 接続の場合は高確率で対応していることが多いです。もちろん中には Thunderbolt 規格でかつ、Thunderbolt の給電で動作するものもあります。

その代わり、USB Audio Class 2.0 ドライバに対応したデバイスは OS 標準ドライバ で動くからどれ使ってもドライバ性能は一緒って話。かなり便利な話。プロだと移動やら出先である程度ちゃんとした音聞きたい、なんてときは便利なんです。

ドライバ性能が一緒だからレイテンシ性能も一緒だろ、とか音質も同じなんだ！？って話は全く違うから注意してね。みんなが「安定性がー」とか言うのは CC モードで動作してたらドライバの問題じゃない。

だから USB 関連の製品について「ドライバがー」という話を聞いたら『ああ、そっちの人ね』って思えばいいです。ドライバ性能は USB では実はそこまで差は出ない。Windows の問題はチップセット相性が非常に多い。もちろん、独自ドライバ製品の場合はまた異なってくるが…

応用性に欠けるデバイスにはなる

もちろん、汎用ドライバを利用して動作するので、デバイスの独自機能にアクセスできない、という問題もあります。まぁ、安価なデバイスでそこまで独自のソフトウェア機能がない場合は多いので問題になることも最近は減ってきました。

そもそも、そういう機能があるデバイスはアプリインストールのときに専用の制御ドライバも一緒にインストールさせちゃいますし、あんまり気にはならないか。

でもプラグアンドプレイができるデバイスは一般 DTM 層にとっては非常に嬉しいですよね。

さぁ DTM 始めよう！
デバイス買ってみた！
電源も入れて USB も繋いだ！
動かない！？

ってことになったら非常にストレスに感じる方もいるでしょう。

だから要は選択肢って話。USB 接続で割とストレスフリーに制作したいけど、細かな設定を追い詰めることはしなくても全然いいよって方は USB デバイスでガンガン制作すればいい。

仕事で少し大変なことを行うようになってくると、ちょっとしたレイテンシーまで気になり始めて、もっと追い詰めたい…もっと多チャンネルを扱って色々制作したい…って話になると Thunderbolt とか PCIe 接続とか HDX とかって話になってくる。

そこまで行ったらもっと勉強が必要になるということ。HDX になるとあんまり必要ないかもしれないけど、中身の仕様は知っていないと運用が難しくなる可能性がある。

USB Audio Class 2.0 の規格自体が既にプロ仕様ではない

これは非常に難しい問題が孕んでいます。

帯域幅の問題
通信の仕組みの問題
クロック同期の問題

それぞれ語ってみようと思います。

ちなみに色々調べていたら、同様のことを既に語っている方がいましたので紹介しておきます。

USB オーディオの Asynchronous 転送フロー制御は破綻した

USB 2.0 の帯域幅について

USB 2.0 は最大 480Mbps という通信速度を持っています。

これは例え最新の USB-C 端子対応のオーディオデバイスを利用しても、端子の規格が USB 2.0 だったら最大通信速度はこの理論値です。USB-C だから速い！ってわけではないと説明しましたね。

簡単に通信速度について計算できるので式を書いてみます。

ここでは RME の公式ページのデータを引用しつつ、計算してみます。引用する意味は後にわかると思います。

24-bit/192kHz ＝ 4.608Mbps
480Mbps ÷ 4.608Mbps ≒ 104ch

つまり In/Out 52ch ぐらいが限界。わかるかなぁ…？

参考: https://synthax.jp/rme-usb2.html

ざっとこんな計算式です。RME のページでは計算がアバウト杉な気がします。

しかし、ここではちゃんとした USB の帯域幅の説明が省かれています。USB は双方向通信デバイスであり、簡単に言うと「行きと帰り」の信号があります。要はオーディオインターフェイスで言うところの In/Out です。

で、この 480Mbps っていうのは USB の全体バスの理論値であり、双方向で合計 480Mbps って言う話です。つまり In/Out 合計 480Mbps だから片側の最大値は 240Mbps かなって考えると思うわけです。

で、その片側 240Mbps であろうという推測は実は間違いで、USB の通信は非常にややこしい事になっていて、片側約 197Mbps が理論値の最大です。これはここで話すとややこしいので後半に説明いたします。

ちなみにこの 24-bit で計算する数値は現代に於いては少々そぐわない場合があります。

何故かと言うと、現代の AD/DA Chip は 32-bit Integer で設計されており、通信自体は 32-bit Integer のデータを多チャンネルで行うデバイスもあります。この場合は以下の計算式になります。

32-bit/192kHz = 6.144Mbps
480Mbps ÷ 6.144Mbps ≒ 78ch

しかし、これはバス帯域全体の理論値で、実際の片側の最大値 197Mbps で計算してみます。

32-bit/192kHz = 6.144Mbps
197Mbps ÷ 6.144Mbps ＝ 32ch

おっと！どこかで見覚えのある数値だ。

2025 年現在の最新デバイスは AD/DA の Chip 自体が 32-bit 動作であり、デバイスの仕様上、最大 24-bit/192kHz と表記されているデバイスでも通信する場合には 32-bit Integer のデータを下位 8-bit を 0 で埋めて通信します。つまり実質 24-bit のデータを 32-bit の枠の中に入れて送っているようです。

上図は macOS 上の CoreAudio の動作を見ている。この見ているデバイスは 32-bit Integer 動作デバイス ではなく 24-bit Integer 動作デバイス なのですが、通信自体は 32-bit Integer で行っているよ、という表記の証明になる。

Windows / macOS のホストと信号をやり取りするときにデータを変換しているのはドライバの役目。

ドライバの仕様と役目

みんな ドライバドライバ っていうけど、こいつが何をしているか知っている人は殆どいない。

CoreAudio は内部がすべて 32−bit Float 制御だそうだ。一部処理に 64−bit Float も利用できるそうだ。

これは AUv3 のプラグインが 64−bit Float の呼び出しをしたときなどに発生する。ややこしいけど Auv3 のプラグインは CoreAudio フレームワーク上で動くプラグインなのでプラグイン側の命令があれば 64−bit Float で処理されるらしい。

CoreAudio の仕様を知る必要があるが CoreAudio が 24-bit 相当の 32-bit のデータをデバイスから受け取ったら内部で 32-bit Float に変換。DAW が 24-bit でくれって言ったら 32-bit Float を 32-bit Integer に変換後、下位 8-bit を切り捨てして DAW 渡すだけ。ドライバの基本動作はこれ。

CoreAudio が DAC にデータを送るときも DAW からやってきた信号を CoreAudio 内部で 32-bit Float に変換、DAC が 24-bit でくれって言ったら 32-bit INT に変換して下位 8-bit を切り捨てして DAC に渡すだけ。これを行うのがドライバの役目だそうだ。

この下位ビット深度から上位ビットへの変換と下位切り捨て処理に関してはディザリングが不要 (量子誤差は発生しない)

Windows の場合もデバイスがどのフォーマットを読み取れるか宣言し、ドライバが変換して信号を渡す。最近のデバイスで USB Audio Class 2.0 ドライバに対応しているのなら 32-bit Integer 通信であることは多く、この宣言に対して処理をしているのがドライバの役目。

まだまだ 32-bit Integer 録音は一般的ではなく、主流になることはないと思いますが、通信自体は 32-bit Integer を行うことが主流になっていると思います。ってか最近主流の AD/DA Chip で 32-bit で動いてないやつ探すほうが大変。

もちろん、設計が古くて非常に安価なデバイスはそうではないだろうが。

まぁ、こういうこと知らない人ばかりだとは思いますが…こういう通信の実態を知っておくことは非常に良いことだと思います。ですから新しいデバイスほど USB で多チャンネル転送するのは難しくなってくる。

USB 規格の実際の速度 (片側 197Mbps)

USB には 480Mbps という理論値がありますが、これが USB オーディオストリーミングでは全く当てはまりません。実際の嘘が紛れているということになります。もちろん、普通のデータ転送時も 480Mbps なんて数値は出ません。

480Mbps が理論上の最高速度なのですが、USB のオーディオストリーミングは アイソクロナス転送 という方式が取られていて、これは USB Audio Class 2.0 で定義されてます。

アイソクロナス転送は完全に理論値を定義できます。

アイソクロナス転送の構造は決まっていて

125 µs ごとのマイクロフレームに最大 3 トランザクション
各トランザクション最大 1024 Byte
つまり 125 µs あたり 3072 Byte がペイロードの上限

1 秒に換算すると…

3072 × 8000（125 µs フレームが 1 秒間に 8000 回）
= 24,576,000 Byte/s
≈ 24.6 MB/s
≈ 197 Mbps

つまり、これが「片方向で実際にオーディオデータに使える理論値」っであり 197Mbs の根拠 です。

USB 2.0 で片側 32ch、In/Out 合計 64ch が設計の限界だとわかるでしょう。

もちろん 192kHz を使わなければもっと安定して多チャンネルを扱えるかもしれませんが、問題が起きるようなチャンネル数を扱うことがないように設計するのが普通ですので、USB 2.0 デバイスで USB Audio Class 2.0 に対応させていこうとすると、最大の入出力の限界がこのあたりにあることは容易に想像できます。

というか独自のドライバ設計をしないと多チャンネル運用が実は大変になってくるということです。現実的に USB 2.0 の USB Audio Class 2.0 対応デバイスは大体 24ch が限界です。それ以上も扱えるみたいですが、USB Audio Class 2.0 の運用上の安全マージンや動作マージン、安定マージンを考えると製品として 24ch あたりが限界という感じ。

ちなみに USB のバス合計の速度は大体 280 〜 320Mbps くらい全体の占有率の 60% くらいが現実的な帯域速度らしく、計算が簡単な 300Mbps (62.5%) くらいで計算してみると…

32-bit/192kHz ＝ 6.144Mbps
300Mbps ÷ 6.144Mbps ≒ 48ch

双方向 48ch って出てくる。8 の倍数に都合のいい数字出てきすぎ。こうなると、最新の AD/DA が USB の In/Out のチャンネルが 24ch 制限があるのは必然な気がしてくるよね。これだったら非常に安定して運用できそう。

オーディオインターフェイスの扱えるチャンネル数の話でアナログ信号ベースで考えるかデジタル信号ベースで考えるか合算で考えるかで数値が異なります。ここでは内部 USB ch の話しかしていません。たまに 30in/32out とか紹介されいるデバイス等ありますが、内部 USB ch は In/Out 合計で 48ch が限界とかめっちゃあります。

もちろん、ほんの十数年前までは USB で 32ch In/Out (合計 64ch) を実現していた製品はありませんでした。世界初だったのは Antelope Audio の初代 Orion32 でこれが USB 2.0 で 32ch In/Out を実現した最初の製品だったと記憶しています。2012 年頃。

ちなみにこの Orion 32 は USB の Band-width (帯域幅) が 80〜90% 必要だって仕様に書いてあって、これが達成できないと運用が難しいという状況があった。双方向 400Mbps というか、アイソクロナス転送の理論値を利用する設計。当たり前だ。

この製品の運用の難しいところは 80〜90% の帯域幅を要求するが、コンピュータ側の USB チップセットのスペックも要求されるため、USB の初期化処理で帯域幅が確保できないと上手く運用できないという結構攻めた設計だった。

オーディオドライバの問題じゃなくてそもそもコンピュータ側と製品側で理論帯域を確保できないって問題が大きすぎた。だから USB の初期化が失敗したら抜き差しのやり直しが起こる。これは USB ホストコントローラ然り、HCD ドライバ然り、USB コア (転送管理) 然り…

もちろん Windows 7 の頃は USB Audio Class 2.0 はなかったので独自ドライバ設計だけど。多分、コントローラ設計は FPGA ＋汎用品だと思うが、弱かったよね。例えば RME や MOTU なんかは FPGA 部分で USB ホストコントローラを実装していたりなんかあるよ。だから安定性が製品にあるって話かな。ドライバの問題ってか USB チップセットやホストコントローラーの問題なんだよなぁ。

この頃はまだ 24-bit AD/DA Chip 全盛期ですね。

ちなみに現在の Orion32+ Gen 4 も USB 2.0 で 32ch In/Out (合計 64ch) 対応を続けている。現在の仕様書には帯域幅の問題については仕様書には書いてなかった。たぶん、USB スタックに関する解決作やコンピュターやデバイス側のチップセットが成熟した影響かと。

ただし、 24ch In/Out (合計 48ch) モードの切り替えができる模様。多分、最新機種でも 32ch モードを USB 2.0 で動かす場合、帯域幅の問題はあるはず。

占有率の問題

USB で運用するときにハブ経由すると起こる問題が占有率の問題です。

問題なのは USB ハブなどを使って、この USB 2.0 の通信の帯域幅を複数のデバイス同士で奪い合うことが起きます。ですから、例え USB 3.0 対応の USB ハブを利用していようが、複数のデバイスで帯域を奪い合い、占有率が低下しデバイスが通信するために確保したい帯域幅が確保できないと運用できなくなるということです。

だからオーディオデバイスはハブを経由しないで直接 Computer と接続しろ、なんていうことが言われます。原因はこれです。まぁ最近の廉価なデバイスなら帯域幅使わないので問題になりにくいとは思いますが、設計が攻めてるデバイスは要注意です。ですから高価なオーディオインターフェイスは Thunderbolt 搭載機が増えているのでしょう。

じゃあ USB 3.0 で通信すればいいじゃん！

これが罠。

これは USB 通信でのオーディオストリーミングについて、かなり深くまで理解していないとなぜ世の中に USB 3.0 製品がほとんど存在しないのか理解できない。

USB Audio Class (3.0) が全く役に立たない

USB 3.0 以降、USB 通信規格は 2025 年現在時点で USB4 まで発展してきたのですが、OS 側で USB Audio Class を USB 3.0 以降、オーディオストリーミングに適応する動きがないため、USB 3.0 の規格を利用する利点が大幅に低下する問題があります。

つまり USB 3.0 の通信帯域幅の恩恵を受けて OS 側のドライバを動かすことができません。中には USB 3.0 接続だけどクラスコンプライアンスモード (OS 標準ドライバを使って動作させること) に対応しているものもあるようですが、中身は USB 2.0 で動いているので USB 3.0 の恩恵が全く受けられない、という とほほ な現状があります。

USB Audio Class 2.0 自体は USB 2.0 ベースで定義されているのでパケット構造や帯域管理が USB 2.0 の仕組みに依存しています。USB Audio Class 2.0 モードで動作する＝ USB 2.0 の帯域幅しか使わない、ということになります。

USB 3.0 SuperSpeed の仕組みを利用する定義は USB Audio Class には存在しなく、USB 3.0 の転送タイプとは別物で USB 3.0 の SuperSpeed Isochronous Endpoints を利用するには、新しいクラス仕様が必要となるが、それが事実上登場していないため (USB Audio Class 3.0 自体はある) オーディオインターフェイスは USB Audio Class 2.0 のまま。

実は 2016 年に USB Audio Class 3.0 自体は出たが、SuperSpeed 転送を本格活用するのではなく、スマホ向け省電力化が主眼であり、PC オーディオやプロ用途の「高帯域ニーズ」は考慮されなかった。そのため USB Audio Class 2.0 がいまだにオーディオ業界の主役のままなのです。

実際の挙動として「USB 3.0 対応」と書かれた Audio Interface であっても、実際のオーディオストリームは USB Audio Class 2.0 準拠 (USB 2.0 High-Speed) で動作しているケースが多い。つまり「USB 3.0 対応」と表記するのは、給電能力やポート互換性を保証する意味合いが強いらしい。

USB 3.0 の通信について

USB 3.0 は SuperSpeed Isochronous Endpoints (スーパースピード・アイソクロナス・エンドポイント) という転送モードが追加され、これを使えば理論上 5Gbps 帯域幅のアイソクロナス転送が可能になりましたが、素晴らしい問題に直面する。

SuperSpeed Isochronous Endpoints は規格上可能でも、OS やチップセットのサポートが長く未整備で Windows / macOS の標準オーディオドライバが USB 2.0 アイソクロナス前提で動いており、OS 側が USB 3.0 の標準ドライバ整備に動かなかった。

このためメーカーが独自ドライバを書く必要があり、開発コスト増 & 互換性リスクが非常に上がってしまう。

USB 3.0 は「パケット再送」や「フロー制御」が強化されたが、それが逆に低遅延を必要とするオーディオ用途には不利になり、オーディオでは「欠落しても遅延なし」が望ましいが、USB 3.0 の仕組みは「欠落しにくいが遅延が増える」方向に設計されているため、プロ用途では USB 2.0 のシンプルなアイソクロナスのほうが安定で信頼性が高くなるという事実があった。

USB 3.0 はコントローラやチップセットごとに挙動の差が大きく、相性問題が多発し、特にオーディオインターフェイスではリアルタイム性がシビアなため、動作保証を取るのが難しかった。

USB 2.0 はすでに枯れて安定していたため、帯域幅が増えても、たくさんの ch を扱うユーザーがほとんどおらず、大規模なものはそもそも Pro Tools HD(X) システムかネットワークシステムで動いていたため、メーカーも「USB 2.0 を使い続ける」ほうが安全であった。

いろいろな問題により、すぐにメーカーは Thunderbolt へ移行した。

通信規格の問題

ここまではすべて帯域幅の問題と USB 3.0 以降の通信規格の問題を解説してきたが、古い USB 2.0 だって万能じゃない。

難しい話だが、説明していく。本当に難しい。

面倒なので理解しなくてもいい。Thunderbolt 接続についても説明する項目を設けようと考えていたため、ここで一緒に比較解説する。

USB の帯域予約の仕組みは アイソクロナス転送 で行われ、フレーム単位で帯域予約を行うが、保証されるのは 1ms または 125µs (1/8ms) 単位。このため細かいタイミング保証はなく、OS 負荷や他の USB 機器の影響を受ける。

☑ 転送モデルの根本差: ポーリング (USB) VS バス直結 (Thunderbolt/PCIe)

USB は “ホスト主導のポーリング”。ポーリングとは 125µs ごとのマイクロフレーム単位でホスト (CPU) が順番に各デバイスへ「今送っていいよ」を命令。デバイスは自発送信できません。このため、フレーム境界待ちが必ず生じ、OS のスケジューリングや他デバイスの状況の影響を受けやすい構造となります。

Thunderbolt は PCIe のトンネリング。オーディオインターフェイスは事実上 PCIe デバイスとして振る舞い、バスマスタ DMA でメモリ上のリングバッファへ直接読み書きできます。ホストの「許可待ち」がほぼ無く、転送がきめ細かく直結的。往復レイテンシを数 ms → サブ ms 級まで詰めやすい (実装依存)。

DMA とはダイレクトメモリアクセスのこと。CPU を介さずにデバイスはメモリにアクセスできる。

☑ 帯域予約と時間粒度: 粗い時間保証 (USB) VS 細かいフロー制御 (TB/PCIe)

USB 2.0 アイソクロナスは「帯域予約」はできるが時間粒度は 125µs (1ms を 8 分割)。

1 マイクロフレーム内で最大 3 トランザクション × 1024B ＝ 3072B/125µs ≈ 24.6MB/s (約 197Mbps) が上限 (片方向・1 エンドポイントあたりの理論値)

予約はできても、その “箱” の中での微細なジッタは吸収しきれない。OS 負荷や他デバイスの予約状況で揺れやすい。

Thunderbolt/PCIe はクレジットベースのフロー制御ときめ細かいトランザクション。転送の刻みが細かく、必要な瞬間に必要量だけ流しやすいので小さいバッファ設定でも安定しやすい。

☑ CPU 負荷とスケジューリング影響

USB はホスト (CPU) 側で「誰にいつ送らせるか」を常に面倒見る設計。アイソクロナスは再送しない代わりに定期処理が必須で、GUI 描画や他割り込みが重なると調度が崩れることがある (古い環境で顕著)。

Thunderbolt/PCIe はデバイス主導の DMA で回せるため、CPU 介入頻度が低い。結果的に負荷スパイクの影響を受けにくい。

☑ エラーハンドリングとドロップの出方

USB アイソクロナス: CRC で検出しても再送なし (遅延を避ける設計)。

稀なエラーでもその場で “プチッ” として露呈しやすい。
USB 3 系では転送一般の信頼性向上機構はあるが、オーディオ用途では HS (UAC2.0) が主流で恩恵は限定的。

Thunderbolt/PCIe: レイヤ内でのリプレイ / 再送があり、しかも極短時間で収束 (実装次第だが ms 〜十数 µs 級)。

☑ ポロジと複数機器

USB はツリー (ホスト 1 本＝配車 1 本)。
ハブ配下で帯域・フレームを共有し、1 台の不調が全体に波及しやすい。
実運用で「1 ポート＝ 1 オーディオインターフェイス推奨」なのはこのため。

Thunderbolt はスイッチド・ファブリック。デイジーチェーンでも各トンネルが独立性高く動作しやすい。

複数のオーディオインターフェイス、DSP、高速ストレージ併用時でも USB より破綻しにくい。

☑ バッファ設定 (最小安定バッファ) の差

USB は同品質ドライバ前提でも、USB は 64 〜 128 サンプルあたりが最小の安全圏になりがち。小さすぎると割り込み・スケジューリングの揺れで XRUN が出やすい。XRUN とは音切れやバリバリノイズのこと。

Thunderbolt は 32 サンプル以下でも現実的に安定する実装例が多く (機材・OS・DAW依存)、往復 (RTL) を 2〜3ms 級まで詰めやすい。

☑ 電磁ノイズ・無線干渉 (特に USB 3.0)

USB 3.0/3.2 の 5Gbps 近傍の放射ノイズは 2.4GHz 帯 Wi-Fi/Bluetooth に干渉しやすいことが知られています。そのためワイヤレス機器と近接配置でドロップやノイズが出る要因に。

Thunderbolt ケーブルはアクティブ＋シールドが厚いことが多く、実地で干渉問題が出にくい (ゼロではない)。

☑ 電源・省電力制御の副作用

USB は Link Power Management (U1/U2/U3) や OS の省電力設定でリンクが軽くスリープすると、復帰でグリッチというケースがある (既定設定だと稀に起きる)。

Thunderbolt はトンネル維持を前提にした電力管理が多く、長時間稼働やスリープ復帰での破綻が少なめ (製品差はあり)。

☑ ドライバ・スタックの成熟度

USB / UAC 2.0: OS 標準で動く反面、超低レイテンシ最適化の自由度が限られ、Windowsでは多くのメーカーが専用 ASIO を提供してカバー。

Thunderbolt: PCIe オーディオに近いドライバ設計が可能で、低レイテンシ志向の最適化がやりやすい (macOS で特に有利)。

☑ クロックとジッタ (誤解されがちな点)

USB は音質的なクロック安定は “転送方式” より “機器の PLL / 内部クロック設計” の寄与が大。ただし USB はホスト配車起因の到着タイミング揺れが小バッファ時の安定度に影響しやすい。

Thunderbolt はホスト配車の揺れが小さく、小バッファでも安定するため、副次的にクロック回りが追い込みやすい (本質は機器設計)。

☑ まとめ (実運用の指針)

安定・低レイテンシ最優先: Thunderbolt (TB オーディオインターフェイス or TB-to-PCIe 系)

広い互換性・コスト優先: USB 2.0 (UAC2.0)

ただし 1 ポート 1 機器、良質ケーブル・セルフパワーハブ、USB 省電力オフ、2.4GHz 機器から物理的分離 (USB3.0時)、ASIO / 専用ドライバ使用などの運用で大幅に安定します。

クロック同期の問題

皆、漠然とクロックはオーディオデバイスのクロックを利用しているのは理解しているが、コンピュータとデバイスがどうやって同期を取っているか、知らない。つか知っている人がいたら結構怖い。

ここでは USB ではどのようにコンピュータから信号を同期してデバイスが受け取るか、を話す。これも AI にある程度資料をまとめてもらったが理解できるか、は、あなた次第だが。

転送方式と非同期方式

すこしややこしいのは USB のデータ転送の方式は「アイソクロナス転送」で「オーディオクロックとUSBフレームの同期の取り方」を分類した 動作モード が「アシンクロナスモード (非同期転送)」となり、データ転送とクロック同期の仕方の話で似たような転送が出てくるので非常にややこしい。

マジでややこしい。

USB の非同期転送 (UAC2.0 asynchronous mode) は、デバイスが “フレーム単位 (125µs) ごとのサンプル数” をホストに通知して調整する仕組みであり、USB フレームクロックとオーディオクロックが「厳密に同期」するわけではありません。

そうなんだよ、USB オーディオストリーミングは厳密にクロック同期は起きていない。

☑ 仕組みの流れ

1. USB の基本フレーム構造

USB 2.0 High-Speed では 125 µs = 1 マイクロフレームが最小単位。
アイソクロナス転送はこの枠の中にオーディオサンプルを載せる。

2. 非同期モード (Asynchronous Mode)

オーディオインターフェイスは自分の内部マスタークロックでサンプルを刻む。
その結果「125µs で得られたサンプル数」は理想値（例: 48kHz なら 6 サンプル/フレーム）から少しズレる。
そこでデバイスは「次のフレームには 6 サンプル送る／次は 7 サンプル送る」とフィードバックエンドポイントでホストに伝える。
概要はかなり異なるが大筋として 29.97 fps に近い概念。

3. ホスト側の動作

ホストはその指示を受けて、受信 / 送信バッファを微調整し、デバイスのクロックに追従。
こうして「長期的にはサンプルレートが一致する」ように制御される。

ポイント

USB フレーム (125 µs) とオーディオサンプルクロックは独立。
非同期モードでは “フレームごとにサンプル数を調整” することで、両者のズレを吸収している。
したがって「USB フレームクロックとオーディオクロックが厳密に同期しているわけではない」。
実際の転送は「平均的に 48kHz に揃う」ようになっている。

例

サンプリングレート 48kHz の場合

理想は 48,000 ÷ 8,000 (マイクロフレーム/秒) = 6 サンプル/フレーム
実際にはクロック差で「あるフレームは 6 サンプル、次のフレームは 7 サンプル」と変動させる。
長期的に平均が 48kHz に収まるよう制御。

☑ 結論

USB 非同期転送は「125µs フレームにサンプル数を割り当てる」設計。

デバイスのオーディオクロックが基準だが、USB フレームと厳密にロックされているわけではない。

実際には「フレーム単位でサンプル数を変動させて平均を一致させる」という制御方式。

実際のクロック同期問題の比較

USB と Thunderbolt 接続におけるクロック同期とジッターについて考える。

☑ ジッタの発生要因

1. フレーム単位でのばらつき

125µs という粒度で「6サンプル / 7サンプル」を切り替えるため、ホストに届くデータは短期的に揺らぎがあるが、これは「転送ジッタ」に相当する。

2. ホストの処理負荷

GUI 描画やその他 USB デバイス処理、OS スケジューラ負荷により、転送完了タイミングがわずかに前後するが、これも「パケット到着ジッタ」として加わる。

3. USB の再送なし特性

アイソクロナス転送はエラーを検出しても再送しないので、欠落が起きれば、ジッタというよりドロップアウトになる。

☑ デバイス側の補正メカニズム

オーディオインターフェイスは「転送ジッタがそのまま D/A に入らない」ように、内部でいくつかの工夫をしています。

1. バッファリング

USB で受け取ったデータはすぐ DA 変換せず、FIFO バッファに貯める。
これにより「フレームごとの揺らぎ」を吸収し、平均的なストリームに平滑化する。

2. PLL (Phase Locked Loop)

デバイスの内部クロックは「PLL」で生成され、USB フレーム到着タイミングと比較される。
PLL は短期的な揺れをスルーし、長期的な平均値に追従。
→ 結果、ジッタが大幅に低減される。

3. アシンクモードの強み

Adaptive Mode (USB クロック追従) ではデバイスのクロック自体が揺れるので音質的に不利。
Asynchronous Mode では「デバイスがクロックマスター」なので、外部ワードクロックや高精度オシレータをそのまま活かせる。

ここでややこしいのは「アイソクロナス転送」と「アシンクロナスモード」です。

☑ Thunderbolt との違い

USB 非同期

「フレーム粒度でのサンプル数調整」という揺らぎ → バッファ＋PLLで平滑化。
平均的には正しいレートだが、短期的にはジッタ成分が存在。

Thunderbolt (PCIe)

DMA で直接メモリとやりとり → フレーム境界が存在しない。
→ 転送ジッタがほぼゼロ、PLL での平滑化が不要に近い。
クロック同期は純粋に「デバイス内クロック or 外部クロック」で決定できる。

☑ 実際の測定・体感

USB オーディオインターフェイス

良質な実装ではジッタは数十ピコ秒レベルに抑えられる。
ただし安価な実装だと PLL やバッファが弱く、クロックジッタがそのまま音質に影響。

Thunderbolt オーディオインターフェイス

PCIe 直結のため理論的に USB より一段有利。
実際に低レイテンシ・高チャンネルでも安定しやすい。

☑ 結論

USB 非同期モードは「125µsフレームごとにサンプル数を調整 → フィードバック → 平均一致」という方式。短期的にはジッタが出るが、バッファ＋ PLL で平滑化して音声クロックに反映。

高品位実装なら USB でも十分に高精度だが、構造上 Thunderbolt (PCIe直結) の方が低ジッタ・低レイテンシで有利。というかクロックの影響を受けやすいとも考えられる。音質評価に影響は強い。USB の場合、劇的な変化は得られない可能性はある。

最後に

これらのことを理解すれば、USB オーディオインターフェイスで音楽制作を避けるべき事象があることが見えてきます。しかし、だから使うな、ではなく、運用方法を臨機応変に考えろ、って話です。

Pro Tools 使いであれば HDX 使っている現状、逃れられない問題がありますが、HDX は同期もサンプル単位で同期しますし、転送は PCIe 直結ですし、Thunderbolt よりもより業務用のシステムを組みやすい、という設計があります。

もちろん、モバイル USB デバイスなんかは、持ち運びが楽で出先で用意に使えるので非常に便利でしょう。ただ、据え置き機としては、HDX や Thunderbolt を利用したほうがいいよねって、言う話です。

いくつかの用語説明

ここでは自分用に用語解説を置いておく。

☑ DMA とは

通常、CPU が I/O デバイスのデータ転送を仲介します。

例：オーディオインターフェイス → CPU → RAM という経路。
これだと CPU に余分な負荷がかかる。

DMA は「CPU を介さずにデバイスが直接 RAM にアクセスする」仕組み。

例：オーディオインターフェイス → DMA コントローラ → RAM。
CPU は「どのメモリに、どのくらい転送するか」だけを指示して、実際の転送は DMA が自動でやる。

DMA のメリット (オーディオ的視点)

☑ 低レイテンシ

CPU を経由しないので、無駄な待ち時間が減る。
Thunderbolt/PCIe オーディオインターフェースはこれでサブ ms 級の転送が可能。

☑ 低 CPU 負荷

CPU は「開始命令を出す」だけで、データのやり取りは DMA が担当。
DAW やエフェクト処理に CPU リソースを集中できる。

☑ リアルタイム安定性

CPU のスケジューリングに左右されにくく、一定周期でデータを流せる。
オーディオでは「ドロップアウトやクリックノイズの低減」につながる。

FIFO バッファとは

FIFO = First In, First Out (先入れ先出し)
「最初に入ったデータが最初に出る」仕組みのバッファ (＝一種のキュー)。
例えるなら「流れるベルトコンベア」や「列に並んだ順番待ち」に近い。

☑ USB のデータ到着は揺らぐ

USB は「125µs ごとにパケットが届く」が、ホストの負荷や転送タイミングで微妙に前後する。
→ そのまま DAC に渡すとジッタやドロップアウトが発生する。

☑ FIFO がクッションになる

受け取ったデータを FIFO に一旦ためてから、DAC のクロックに従って一定速度で吐き出す。
→ USB の揺らぎを吸収し、安定したサンプリングクロックで DA 変換できる。