#38 USB Audioについて(その6 Host側のドライバについて)

6 comments

Posted on 10th 2月 2010 by admin in ものつくりの現場から

 前回の記事(#37)について早速「えるえむ」さんからコメントをいただきましたので、その回答も兼ねてHost(PC)側がどのようにして音楽データをUSB_Bus上に送り出しているのかということについて簡単に説明しておきます。Host側の動作を理解していただいた上でJitterなどの話を進めたほうがわかりやすいと思いますので。

Z38-1

<図-38-1 USB Audio 関連Softwareの階層>

 USB Audio 機器ベースのPC_Audioに関係しているドライバ、アプリケーションソフトウェアの構造を簡単に示したものが図-38-1です。このような階層構造(OSI)は25年以上も前に大型計算機の通信ソフトウェアで使われてきたものです。同図はWindowsPCの場合ですが、MacOS XやSolaris,Linuxも同じような構造をしています。一番ケーブルに近いところはハードウェア(USBコントローラLSI)でPCI_BusやCardBusスロットを経由する場合もあります。最近は大半がMother Boardに実装されているChip Set(LSI)に組み込まれ、内部のSouth(PCI) Bridge経由でCPUのBusに接続されています。これらのコントローラにはLowSpeedとFull Speed(12Mbps、USB AudioはUSB 2.0と称していますが、ほとんどの製品はこのFull Speedで動作しています。)を受け持っているUHCIあるいはOHCIアーキテクチャのコントローラ、High-Speed(480Mbps、昔の呼び方ではUSB 2.0)を受け持つEHCIアーキテクチャのコントローラの3種類があり、それぞれに対応したミニポートドライバがWindowsやMacOSなどのOSに既に組み込まれています。ちなみにWirelessUSBの場合はWHCI、SuperSpeedUSB(USB 3.0)の場合はXHCIと呼ばれます。IEEE1394の場合もOHCIアーキテクチャと呼ばれています。

 RAL-2496UT1などのUSB Audioの場合はUHCIかOHCIアーキテクチャのコントローラ経由で通信することになります。UHCIというのはintelが提唱したアーキテクチャでintelのChip Set以外ではVIAのChipで使用されており、ほとんどの処理をSoftwareによるポーリングで行うので構造が簡単ですがソフトウェアのオーバーヘッドが大きく、リアルタイム処理向きではありません。対抗するOHCIはOpenの頭文字が示すようにCompaq,NS,Microsoftによって提唱され、NECやNvidea、AMDなど多数の会社が採用しているアーキテクチャで、ほとんどの処理をコントローラ自身が自分で行います。Software(CPU)はDescriptor ChainをSetしてコントローラに実行指令を出すだけでよいのでリアルタイム向きで優れているのですが、その分コントローラの設計が難しくなり構造も複雑ですので価格が高くなります。実際にOHCIアーキテクチャが使われているChipはAMD-CPU用のChip SetおよびNECのUSBコントローラChipです。

 USB DACなどのUSB Audio出力ではIsochronous転送が使用されていますので、全体のCPU負荷が小さければOHCIでもUHCIでも動作に差はありませんが、音楽編集や録音、Mixingなどでインタラプト転送、コントロール転送、バルク転送などが使用されている場合はUHCIよりはOHCIの方を使用したほうがよい結果が得られると思います。なぜなら、OHCIでは32mSごとに最低1度はインタラプト転送を受け付けたり、1フレーム期間内に複数のコントロール転送や2回以上のバルク転送を実行できますがUHCIではこれらは実行できません。

 USBポートにUSB機器が接続されるとまずLow SpeedかFull Speedかが2本の信号線(D+とD-)の状態で判断されます。続いて、USB機器の種類や属性を引き出すためのGET_Descritorが発行され、機器側はDevice Descriptorを返送します。Descriptorを解析した結果USB Audioの規格に準拠したAudio DeviceであることがわかればAudio Class Driverとしてusbaudio.sysがロードされます。続いてDevice Managerによって、その上にKernaelmixerあるいはASIOなどの中間のDriver(Client Driver)がロードされます。さらにその上にiTunesやMedia Player, foobar2000などのアプリケーションがユーザー(みなさんです)によってロードされれば、最終的に図-38-1のような階層構造が出来上がります。

 この図からおわかりのようにRAL-2496UT1などのUSB Audio機器はASIOドライバから見て、下位のusbaudio.sysを経由してにアクセスされますので「USB Audio規格に準拠しているUSB Audio機器は基本的にASIOドライバに対応している」ということになります。したがって、iTunes(QuickTime Player)などのアプりケーションがASIOドライバを使用するようにアプリケーションの入出力を設定すればOKです。その設定を行わなければKernelMixerが有効になりますのでRAL-2496UT1などのUSB Audio機器へのアクセスはKernelMixor経由となります。Windows Vista SP2以降(Windows 7も)では従来のDirectX(Sound)だけでなくKernelMixer内部の機能を選択(パススルー)することができるWASAPI(Windpws Audio Session APplication Interface)というAPIが新たに用意されていますので、これを使用してUSB Audio Deviceを排他モードに設定し、bit数やfsをWAVファイルのヘッダ部に書かれているものを指定するという方法もあります。もっと、簡単な方法はUSB Audio DeviceのDescriptorの記述を16bit/44.1kHzのみなどにしてしまうという方法もあります。この方法で16bit/44.1kHzのWAVファイルのみを再生すればKernelMixer内部のSRC機能を実質的にPassさせることができると思います。FostexのHP-A3の場合は、Descriptorに16bit/96kHzと24bit/96kHzにのみ対応としか記述されていませんので、KernelMixerなどのSRC機能を使用せずに16bit/44.1kHzのWAVファイルをオリジナルとおりに再生しようとするとPC側でエラー表示がでて再生できません。したがって、先ほど「USB Audio規格に準拠しているUSB Audio機器はASIOドライバに対応している」と書きましたがUSB Audio機器側がSRCなしでASIOドライバを通して送り出されて来る音楽データのbit数/fsに対応していなければなりません。RAL-2496UT1では16bit、24bitの各解像度で44.1kHz,48kHz,88.2kHz, 96kHzの各fsに対応していますのでWASAPIやASIOドライバを使用すれば、PC側のSRC機能なしでたいていのWAVファイルやAIFFファイルをそのまま再生できます。iTunes(QuickTime)のWASAPI使用の設定方法についてはラトックプレミア楽天市場店店長Blogを参照してください。

Z38-2

<図-38-2 WAVファイルがUSB転送のためのIsochronous Out パケットに編集されるしくみ>

 図-38-2をご覧ください。iTunesなどのアプリケーションは指定されたAIFFもしくはWAV(どちらも非圧縮PCM)ファイルをHDDやSSD、FlashMemoryなどの記憶媒体から読み出してRAM上で編集します。編集といっても簡単でファイルのヘッダに格納されているfmtチャンク(format情報。chunkは'ぶつ切り'のひとかたまりという意味です)内部のbit数(L,R各チャンネルあたりの)やfs情報を元に、dataチャンクから取り出した実際のサンプリングデータのブロックを下位のドライバに引き渡すだけです。usbaudio.sysではこの上位から渡された10mS(10フレーム)分のデータブロックを各フレームのパケット用にfs/1000組ずつ(44.1kや88.2kの場合の分け方は#37参照)整列させます。OHCIの場合にはとても簡単で各パケット分のデータと荷札(Packet-IDと順番、Timestampなどが記載された)、次のメモリブロックの場所を記載した送り状をひとつのメモリブロックに格納してチェイン上に並べておきます。そしてOHCIコントローラに最初のメモリブロックの場所を指示して実行命令を出しておけば後はOHCIコントローラが内部のインターバルタイマの1mS間隔にしたがって、USB Bus上に送り出してゆきます。UHCIコントローラのミニポートドライバは作ったことがありませんのがこんなに簡単(CPUのすることが少ない)ではないようです。

 この図からおわかりのようにHost(PC)側ではfsによるサンプリングなどは行っていません。サンプリングされたデータ列をデータが作成されたbit数、fsに基づいてRAM(メモリ)上で整理しているだけです。サンプリングレ?トや解像度を変換しない限り非圧縮のPCMデータに対してはbitの追加や変更などは行いません。また、HDDなどの記録媒体に関係なくRAM上に読み出されたデータは同一です。 したがって、「HDDなどの回転体を使用するとJitterが増えて音が悪くなる」とか「PCのClockがゆらいでJitterが増える」、「PCのClockがUSBケーブルを通ってUSB Audio機器側のfsに影響する」というような評論記事はすべて???です。実際の再生はUSB Audio機器内部で作成したClockによりAudio信号に変換されます。したがって、再生時(I2S作成時)のClockはデータ送り出し側とは完全に独立していますのでAsynscということになりますが、曲の最初を同期させなければ正しく再生できませんので何らかの方法が必要です。そこだけに注目するとSYNCということになり、Isochronous転送は受信が終わるまでバイト数がわからず、しかもそのバイト数でしかfsを判断できないということを考えればAdaptiveということにもなります。要はIsochronous転送の動作モードの指定はどうでもいいのです。プロトコルアナライザで観測している限りでは動作モードbitをいろいろ変えてみても何も変わりません。

 USB Audioで問題なのはいろんなアプリケーションが動作している場合、Isochronou転送用のパケットが用意されていないことがあるということです。また、WindowsもMacOSもUSBのミニポートドライバなどが特権モード(Kernelモード)から優先度の低いユーザモードに移されてしまいましたので、PowerManagementなどの特権モードで動作するドライバにPacketデータのセットが邪魔をされてしまうことがあります。これらの問題が「ブチッ!」という再生時の音切れの原因のひとつになります。実際にWindowsVistaではNEC製USBコントローラを使用した私たちの製品(PCIボードおよびCardBus Card)の動作が非常に遅くなります。いろいろ調査したところMicrosoftのPowerManagementドライバが常時USBコントローラ(OHCI/EHCI)を監視しておりバルク転送などの動作の邪魔をしていることがわかりました。でもMicrosoftからは「悪ぃ、悪ぃ、Windows7では直しておくよ」という回答でした。約束通りWindows7では修正されていますがVistaユーザはどないすれば….

 同様にMicrosoftではIsochronous Packetへのデータセットが間に合わずに発生する音切れ(Scratch noise like a vinyl recordというらしいのですが)について統計を取って調査をしています。その結果、この音切れを発生させる最大の要因はPowerManagementであり、ノートPCをバッテリで動作させている状態が最も発生しやすいとの結果を発表しています。「PC_Audioで最もいい音を出すにはノートPCをバッテリ駆動で動作させる」という記事をよく見かけますが、これは音切れの発生率が最も高くなることがあるということに気をつけてください。

 余談ですがintel-Macが発表される1年くらい前にMacOSでもUHCIをサポートするということが発表されたことがあります。その事実が示すようにintel-MacのUSBポートはUHCIアーキテクチャを採用しています。OHCI用のドライバはまだ残されていますのでPCIeボードを使用すればOHCIアーキテクチャが使用できますが、NECのUSBコントローラ搭載のPCIeボードはありません。NECのUSB 3.0コントローラ搭載のPCIeボードでEHCIとOHCIを使用するという手はありますが、USB 3.0のDriverはまだ提供されていません。通信用のファームウェアを書くたびにMC6800系はよく出来ていたのになぁ~と懐古趣味に浸っています。でも、このScratchノイズが解決すればUSBはPC_Audioの信号伝達手段として最も普及すると思います。

 次回はJitterについて説明します。

#37 USB Audioについて(その5 bit数とSampling Rateはどのようにして決められるか)

2 comments

Posted on 2nd 2月 2010 by admin in ものつくりの現場から

 前回の図-36-1を理解していただけましたか? 同図のようにUSB信号線上はUSBの転送レート(この場合は12Mbps)によるPacket転送であり、USB Audio DataそのものはPacketの中の単なるバイナリデータとして扱われます。データはUSBの転送ルールにしたがってIsochronous転送されますので、USB-Host(PC)やUSB Audio Deviceのコネクタ部や基板パターン、PHY(Chipの物理層)周辺、ケーブルなどのどちらかといえばアナログ部の影響を受けます。何らかの問題がある場合はデータの不一致や誤認識、欠落が発生します。これが発生しないようにクリアすべき電気的な基準がUSB規格で規定されています。

 Full Speed(12Mbps)も低速とは言え高速シリアル転送ですのでジッタに関する規定もあり、測定時には一目で判定できるようにアイパターンが規定されています。これまでの私たちの経験では、USB Audio機器が正しく認識されないようなケーブルや、データ転送の途中で転送を止めてしまうようなケーブルはこのアイパターンテストで不合格となります。

 USBの転送時に使用されるClockは両側のUSBコントローラの発振回路(TAS1020Bでは6MHzの水晶を使用し、内部のPLL回路でFull Speed転送に必要な48MHzを作成しています。)でつくられていますが、Audio DataがIsochronous Packetとして転送される場合、受信側は送信側のSpeedに合わせるため、PLL回路を動作させて送信側のClockに追従してLockさせたClockを使用します。したがって、前回の図-36-1からもおわかりのようにPCからのUSB Clockおよび受信側のUSB ClockはAudio DataをI2Sに変換するためのAudio Clockとは全く別のClockです。Host(PC)から送り出されてくるUSB DataからS/PDIFのようにAudio用のClockを作成しているわけではありません。ましてやPCのClockがアプリケーションソフトウェアの動作により影響されてゆらいだままノイズを載せてUSB Audio機器に入り込んでくるということはありません。iTunesでCover Flowなどを動作させるとUSB Audio接続のAudio機器~ブツブツ音が聞こえるというのは別の原因です。

 PCとUSB Audio機器双方のUSBコントローラ相互間はSYNCモードですが、PC側と機器側のAudio Clock(LRCLK,MCLK)は完全に独立したClockを使用しますので一般的な定義ではASYNCということになります。しかし、サンプリング周波数と位相(LRCLK)、各Ch.のbit数が一致しないと音楽の始まりやつながり、テンポや音程が無茶苦茶になってしまいます。MIDIの場合は音符のコードや小節ごとの同期コードなどが決められていましたがUSB Audioの場合はそんなものは何もなく、いきなりバイナリ('0'と'1'の組み合わせ)データが送られてきます。したがって、単なるASYNCではStart bitもStop bitもありませんのでどこが曲の始まりか、どちらがL.Ch.のデータかR.Ch.のデータかわからなくなってしまいますので送り出し側(PC)と受信側(USB Audio機器)の間でSoftware(プロトコル)レベルで同期をとることが必要です。

 図-37-1を参照してください。前回の図-36-1ではfs(LRCLK)が48kHzで1mSのUSB Frame間に整数個のデータがきちんと収まる場合を図示していますが、図-37-1ではCDを非圧縮でRippingした44.1kHzのデータの場合を図示しています。CDがUSBよりも10年も前に普及し、音楽ソースとして無視できない存在ですのでUSB Audioの規格を決めた人達もずいぶん苦労されたようですが、この44.1kHzや88.2,176.4kHzというfs(1msで割り切れない)にはずいぶん苦労させられます。これまでも何度かお話しましたが、44.1kHzの場合、USB Audio Driverの10mS分のスタック上に1パケットあたり44サンプル分のデータが9パケット分と45サンプル分のデータが1パケット分積み上げられ、順番にUSB Bus上に送り出されます。

37_20100202a2

<図-37-1>fs=44.1kHzの場合

 以下は図-37-1を参照しながら読み進めてください。

 まず最初のPacketの受信が終了し、次のFrameのSOFが検出されると最初の44組のデータをI2Sに変換しなければなりません。ただし、LRCLKは44.1kHzですので次のSOHまでの1mSまでの期間に2.27μS(1.0mS – 1/44.1k x 44 )の隙間(GAP)ができてしまいます。音楽の途中でこんなGAPがあると音が狂ってしまったり、バチッというLPレコードの引っかき傷のような音が出てしまいます。そのため、次のパケットの先頭一組を取りだしてきてくっつけます。2番目のパケット内のデータを送り終わった後では4.54μS、3番目のパケット内のデータを送り終わった後では6.81μS…とだんだんGapが大きくなり、9番目のパケット内のデータを送り終わった後には20.43μSとなります。この時点で10番目のパケットの最初の組をくっつければ10番目を転送した直後は11番目(最初のFrameは転送しないので)のSOHに一致します。したがって、USB Audio機器側でもPacket10個分(10mS分)のバッファメモリを用意すればSoftwareやHardwareが簡単になりますが、16bit/44.1kHzで1,764バイト(4×441)、24bit/96kHzにも備えておくとすると5,760バイト(6×960)のRAMが必要となります。現時点で入手可能なUSB Audio StreamコントローラのTAS1020Bを例に取るとEndpointやBufferとして使えるRAMは最大で1304バイト程度ですので10mS分のバッファは用意できません。TAS1020Bではひとつながりのリング状にバッファを設定することに(Circular Buffaer)よって、この44.1kHzベースのAudio dataに対応しています。

  パケット内のデータを取り出しI2S(LPCM) Streamに変換するためには各Ch.(L,R)のbit数、fsに関する情報が必要です。USB DACやUSBトランスポートなどのIsochronous Out転送の場合、これらのパラメータを決定する主導権はPC上のSoftware(iTunes/QuickTime PlayerやMedia Player,KernelMixerなど)にあります。また、実際に使用する上でも、楽曲ファイルのフォーマットに従って転送が行われ、USB Audio機器側では何の操作する必要がないほうが最も使いやすいと思います。たとえば16bit/44.1kHzでRippingされた楽曲ファイルを選択すればUSB Audio機器やAudio機器側で何も操作せずとも16bit/44.1kHzで再生され、24bit/96kHzでRippingされた楽曲ファイルを選択すれば同様に24bit/96kHzで転送されて再生されるという具合です。

 Isochronousの転送モードがASYNCであるか、SYNCかAdaptiveであるのかに関係なくUSB AudioではHost側(PC)がUSB Audio Deviceから取得したDevice Descriptorを解析し、その機器が24bitにも対応しているのか、それとも16bitだけにしか対応していないのかInterface descriptorを元に判断します。そして、Audio Data Streamに関するInterface Setごとに、ReadyかどうかをRequestを出してUSB Audio機器側に問い合わせます。

 本Blogの#33-図-2に示すRAL-2496UT1の例ではInterface Set#1が16bit用、Interface set#2が24bit用として記述されていますので、PCからSet#2はReadyかどうか、Set#1はReadeyかどうかというRequestが発信されてきます。USB Audio機器(RAL-2496UT1)側ではこの時点ではPCからどんなフォーマットのAudio Data Streamが送られてくるのかということが不明ですので、とりあえず、すべてのRequestに対してReadyを返しておきます。

 PC側でiTunesやMediaPlayer,fooberなどのアプリケーションを起動するとQuickTime Player, Control panel, アプリケーション自体の設定に基づいて、bit数を指定するためのSet InterfaceRequestがUSB Audio機器に送られます。このRequestに対してUSB Audio機器がReadyを返せば、その時点でそれ以降のAudio Data Stream転送で使用されるbit数が決定されることになるわけです。RAL-2496UT1の場合は図-37-2のように音楽データ(Isochronous)に先立って、Set Interfaceが送られて来ます。ただし、bit数が既知(ひとつ前の楽曲再生と同じ場合はSet Interface Requestは発行されませんので、USB Audio機器側は同じbit数のモードを維持し続けなければなりません。次に再生する楽曲のbit数が変更される場合は前述のようにそのbit数に対応したSet InterfaceがHost(PC)から発行されます。図-37-2の場合は24bitのAudio Data Streamを送るということをPCからRAL-2496UT1に通知していることを示しています。

37-20100202b

Packet 5102 がSET_INTERFACE Request で Alternative Setting#2(02, Ch.あたり24bit)を指定しています。

<図-37-2 USB Host(PC)からUSB Audio Device に対するbit 数の指定>

 サンプリング周波数(fs)の指定に関しても同様にHost(PC)はInterface Descriptorを参照します。#33-図-2RAL-2496UT1の場合は16bit、24bitそれぞれのbit数で44.1,48,88.2,96kHzの4種類に対応していると記述していますのでPCはiTunesやMediaPlayerなどの指定にしたがって、どれかのサンプリング周波数に基づいてファイルから読み出したAudio Dataを{(bit数/8) x (fs/1000)}バイトずつ一つのパケットに詰め込みます。例えば24bit/96kHzの場合は(6 x 96)バイトを一つのパケット(1mS分)に詰め込むことになります。

 その後、Audio Dataが詰め込まれたパケットを10個ずつusbaudio.sysに渡して転送実行を命令します。これらのパケットがぞろぞろとUSB bus上を一列縦隊行進しながらUSB Audio機器にやってきます。ところがUSB Audio機器側には、bit数の時のように届く予定のAudio Dataに関してあらかじめfsに関する情報は何も通知されていません。したがって、USB Audio機器側では届いたPacket内のAudio Dataのバイト数からfsを算出しなければなりません。各Ch.のbit数はあらかじめわかっていますからバイト数を6(24bit)もしくは4(16bit)で割り、その商に1,000を掛けるとfsが得られます。前述のようにfsが44.1kHzの場合には商が44であったり45であったりしますが、それはF/Wでfs=44.1kHzと処理することにすればOKです。88.2kHzの場合には88組のパケット4個に続いて89組のパケットが1個という順番で送られてきますので商が88か89だったらfs=88.2kHzと処理することになります。

 Isochronous転送でモードがASYNCの場合にはプロトコルの規格上はDevice側で使用するfsを問い合わせるRequestとそれに対する応答用のEndpointがやり取りされることになっていますが、現実にはそんな面倒なことは行われていません。また、規格上はパケット内のバイト数をCheckしてfsを割り出すのはAdaptiveモードですが、Isochronous Out EndpointのMode bit(ASYNC、SYNC,AdaptiveのModeセット用)をいくら換えてもHost側の挙動には変化がありません。USB Audio機器側がfsを検出するためには、Host(PC)側はパケットサイズによって通知するしかありません。

 Deveice DescriptorのInterface Setの記述方法を一つのbit数/fsごとに記述する方法によりSet Interface requestでbit数/fsを選択する方法もありますが、KernelMixerなどが、機器が対応している最高の組み合わせに内部で勝手にサンプリングレート変換を行ってしまうという問題があります。また、USBマイコン側の問題としてはDevice Descriptor用にそんなに大きなEndpointを用意できないという問題もあり難しいところです。また、QuickTimeやFooberなども指定したbit数が常に使用されてしまうという問題がありますので、この記述方法は最近ではあまり使用されていません。 ただし、独自のfs、bit数設定用のApplicationをあらかじめインストールするタイプのUSB DACなどはこの方法を採用していますが、独自のアプリケーションやドライバをインストールしなければならないこと、OSやiTunes、MediaPlayerなどのVersionが変わるたびにそれらに対応した新しいドライバやアプリケーションが必要になるという問題などがあります。 また、FOSTEX HP-A3のように16/96kHzと24/96kHzにのみ対応と記述されたDevice Descriptorを持つUSB Audio機器の場合、KernelMixerなどがDescriptorに基づいてUSB Audio出力のfsをすべて96kHzにサンプルレート変換して送り出します。たとえば16/44.1kHzでRippingされた音楽ファイルを再生する際にはPC側のSoftwareでサンプルレート変換が行われます。この場合もfsの指定などのRequestはPCからは発行されず、すべてのIsochronousパケットのサイズ(バイト数)が576または384となるだけです。

 USB Audioでbit数やサンプリング周波数が決められている方法はこのようなシンプルな方法です。プロトコルの規格上はいろいろと面倒なことが記載されていますが、USB DACやUSBヘッドホン、USBスピーカーなどのIsochronous Out専用の場合はこのような簡単な方法が採用されています。

 「USB Audioでのサンプルレートの指定方法」について昨年10月にYHさんからコメントをいただいておりますので回答させて頂きます。

 ご質問の件は上記のように「パケット内のバイト数により指定されている」というのが現実です。USB Audioの規格書では「implicitな指定」と記述されています。また同じコメントで「データパケットの間隔をPLLで逓倍してDACのClock(I2SのLRCLKやMCLK)を作成している。」と記述されている他のblogに関しても言及されていましたが、これはYHさんのおっしゃるとおり正しくありません。DAC用のClockはPC側のクロックとは全く関係なくUSB機器側で作成します。USBで必要な48MHzや12MHzなど内部のマイコンの動作クロックの作成に使用される6MHz水晶発振子を共通に使用して周波数シンセサイザで24.576MHzや22.5792MHzを作成しています。あるいは別に搭載されているAudio専用の水晶発振回路でそれらの周波数のClockを作成しているかのどちらかです。どちらを選ぶかはそれらのMCLKそのものやMCLKから作成されたfs(LRCLK)のJitterが少ない方ということを基準にすればよいと思います。前回の#36でも説明しましたがUSBのSOFの間隔(Frame間隔・1ms)は一定ですが、パケットとパケットの間隔は一定ではありません。したがって、YHさんのご意見が正しいということになります。

 「バイナリデータの不一致」に関して「えるえむ」さんからも昨年12月にコメントをいただいております。今回の記事をお読みいただければおわかりのように、ファイルから読み出したバッファメモリ上の音楽データは、当然HDDなどに記録されたものと「バイナリ一致」が保証されていますが、usbaudio.sysへの10ms分・10個のパケットの引き渡し以降は一切、Errorチェックも訂正もありません。Isochronous Dataが壊れているというErrorは通知されますが再送要求などはありません。また、Isochronousデータは受信が終わって初めてサイズがわかるという代物です。なぜ、Errorチェックや再送要求があるBulk転送が使用されないのかということは別稿で説明します。

 USB Audio Streamの転送についてはこれくらいにして次回はJitterについて実測結果などをもとにお話を続けたいと思います。