約 4,166,139 件
https://w.atwiki.jp/psemu/pages/28.html
はじめに GPUプラグインAdrenaline's Software GPU Plugin(gpuAdrenalineSoft) AmiDog's GPU Plugin (gpuadgpu) DarkMan's D3D Driver(gpuDemoHard) DarkMan's GPU Recorder(gpuRecorder) DarkMan's Redirect Log Plugin(gpuLog) DarkMan's Speed Test Driver(gpuRaw) D3D renderer(gpuImpactD3D) OGL renderer(gpuImpactOGL) Directx7 LinuzAppz Gpu Driver(gpuDx7) Dr.Hell's Action Replay GPU Wrapper(gpuHellAR) Dr.Hell's GDI Driver(gpuHellGDI) Duddie's Soft Driver(gpuDudSoft) edgbla's Software Rendering Plugin EI's soft Driver(gpuEZHsoft) FAST D3D renderer(gpu_fast) FoxFire OpenGL Renderer(gpuFoxOpenGL) GSdx Kazzuya OpenGL Driver(gpuKazOpenGL) Kazzuya's Software Driver(gpuKazSoft) Knack's Soft Driver(gpuNakSoft) Kurimpa Lewpy's 3dfx/Glide GPU(gpuLewGlide) [NextGL](gpuNextGL) [Next3D](gpuNext3D) [NextSoft](gpuNextSoft) Nik's Direct3D Renderer(gpuNikD3D) Null Driver(gpuNull) psx emulation cheater(gpupec) Pete's OpenGL2 Driver(gpuPeteOpenGL2) Pete OpenGL2 Tweak P.E.Op.S. OpenGL Driver(gpuPeopsOpenGL)Pete's GPU (OpenGL, D3D, DX6) P.E.Op.S. Soft Driver(gpuPeopsSoft) P.E.Op.S. Soft Driver Refresh Segu Direct3D Driver(gpuSeguD3d) Zen OpenGL Driver(gpuZenOpenGL) SPUプラグインDarkMan's SPU Recorder(spuRecorder) ePSXe内蔵プラグイン Eternal SPU Plugin(spuEternal)Iori's Directound Driver(spuIori) Andy's SPU Audio Driver(spuAndy) Kazzuya DirectSound Audio Driver(spuKazDSound) No Sound(spuNull) Null2's Audio Driver(spuNull2Mixer) Null Sound Driver(spuNull7) P.E.Op.S. DSound Audio Driver(spuPeopsDSound)Pete's DSound Audio SPU(spuPeteDSound) Pete's MIDAS Audio SPU(spuPeteMidas) P.E.Op.S. Sound Audio Driver(spuPeopsSound_110b) P.E.Op.S. Sound Audio Driver(spuPeopsSound_110b) Prodigy sound driver(spuProdigy) Seal Audio Driver(spuSeal) CDRプラグインASPI Driver(cdrASPI) Barrett-Kazzuya CDR Driver(cdrBarrett) DAO Image Driver(cdrDAO) |Zink88|'s Disk Image Driver(cdrDiskImage) Duddie's ASPI Driver(cdrDudAspi) edgbla's CDR Plugin ePSXe内蔵プラグイン ISO Image Driver(cdrISO) Linuzappz Iso Cdr Driver(cdriso) Mooby2 cd disk image driver(cdrmooby2) Null Driver(cdrNull) P.E.Op.S. CDR Driver(cdrPeops) SaPu's CD-ROM Plugin(cdrsapu) Segu ASPI32 Driver(cdrSeguASPI) SSSPSX CDR Plugin [INTERNAL](内蔵プラグイン) Tratax ASPI Driver(cdrTrxASPI) VirusCDR Image Driver(cdrVirus) Xeven's Cdr Driver(cdrXeven) PADプラグインDInput Keys Driver(padDIKeys) Duddie's DirectInput Mouse Driver(padDudDIMouse) Dr.Hell's WinMM PAD Driver(padHellMM) Harakiri Pad Plugin(padHarakiri) Kazzuya GamePad DInput Driver(padKazDInput) Keyboard Driver(padkey) N-Rage Plugin(padNRagePlugin) Null Driver(padNull) nuvee psx pad(nuvee_psx_pad) pad Gnneco [en, DI7](padGnneco) Pokopom XInput Pad Plugin(padPokopom) Segu Direct Input Joystick(padSeguDIJoy) Segu Direct Input Keyboard(padSeguDIKey) Segu Direct Pad Pro Driver(padSeguDPP) SSSPSX PAD Plugin(PadSSSPSX) SSSPSX PAD Plugin Zeta(PadSSSPSX (Z)) SSSPSX PAD Plugin Pressure Mod(PadSSSPSX Pressure Mod) TwinPad(padTwinPad) NetPlayプラグインCyberPad(cpka) netSock(netSock) PS4NET はじめに プラグイン式PSエミュの元祖はPSEmuProなのでPSEmuPro系プラグインとも呼ばれる。 PSEmuPro系プラグインはシステムファイル（dll）なので、エクスプローラのフォルダオプションで「すべてのファイルを表示」しないとエクスプローラからは見えない。(WindowsXPでは最初からdllは表示される) プラグインの設定はレジストリの「HKEY_CURRENT_USER\Software\Vision Thing\PSEmu Pro」に記録される。 初期化、アンインストール、設定のバックアップをしたいときに使う。 ePSXe、PCSXなどのプラグイン式エミュレータで使用できるプラグインにはGPU（グラフィック用）、SPU（音楽用）、CDR（CD読込用）、PAD(パッド用)がある。 いろいろなプラグインがあるので自分のPC環境にあったプラグインを選択するとよい。 プラグインは特別な理由（不具合等）がない限り基本的に最新版を使用するとよい。 GPUプラグイン 基本的にソフトウェアプラグインとハードウェア機能(D3D,OpenGL)を利用したプラグインに分かれる。おすすめはPete's又はP.E.Op.S. 各GPUプラグイン共通の注 動作速度が速すぎるときはGPUの設定メニューからFPS（一秒あたりの描画数）を制限する。 ウィンドウモードよりフルスクリーンモードのほうが軽い。 解像度が高いほど重い。ちなみにPS実機の解像度は320x240が多く、軽い場面では最大640x480。 ウィンドウモードとフルスクリーンを切り替える時はデスクトップの色数とGPUの色深度を一致させる。 Intelの古い内蔵ビデオチップのようにデスクトップで24bitまでしか選べないときは、両方16bitにするか、デスクトップを24bitにしてGPUをフルスクリーンの16bitにする。 フレームスキップを使うとPCの処理能力が足りないときでも速度を出せるが、互換性が落ちる。 Adrenaline s Software GPU Plugin(gpuAdrenalineSoft) ダウンロード：gpuadrenalinesoft.zip AmiDog s GPU Plugin (gpuadgpu) 公式サイト：http //psx.amidog.se/doku.php DarkMan s D3D Driver(gpuDemoHard) DarkMan s GPU Recorder(gpuRecorder) DarkMan s Redirect Log Plugin(gpuLog) DarkMan s Speed Test Driver(gpuRaw) 公式サイト：http //web.archive.org/web/20040609200213/http //mrdario.tripod.com/ ダウンロード：gpudemohard092.zip ダウンロード：recorder20.zip ダウンロード：gpulog10.zip ダウンロード：gpuraw.zip D3D renderer(gpuImpactD3D) OGL renderer(gpuImpactOGL) ダウンロード：gpuimpact.zip Directx7 LinuzAppz Gpu Driver(gpuDx7) ダウンロード：gpudx7.zip Dr.Hell s Action Replay GPU Wrapper(gpuHellAR) Dr.Hell s GDI Driver(gpuHellGDI) 公式サイト：http //drhell.web.fc2.com/ Duddie s Soft Driver(gpuDudSoft) ダウンロード先：http //web.archive.org/web/19990427181519/http //www.psemu.com/ edgbla s Software Rendering Plugin ダウンロード先：http //www.emucr.com/search/label/gpuBladeSoft? max-results=12 E}I{ s soft Driver(gpuEZHsoft) 公式サイト：https //web.archive.org/web/20150402032503/http //ej.at.tut.by/ FAST D3D renderer(gpu_fast) ダウンロード：gpu_fast.zip FoxFire OpenGL Renderer(gpuFoxOpenGL) ダウンロード先：http //web.archive.org/web/19990427181519/http //www.psemu.com/ GSdx ダウンロード先：http //forums.pcsx2.net/Thread-GSdx 公式SVN snapshot：http //buildbot.orphis.net/pcsx2/ PS2のエミュレータで使用されるGPUプラグインであるが、GSdx 0.1.10(rev 854)以降 はPSエミュレータでも認識する。 公式SVN snapshotからダウンロードした場合は、pcsx2-xxxx-windows-x86\pluginsの中に入っている。 Kazzuya OpenGL Driver(gpuKazOpenGL) ダウンロード：gpukazopengl.zip Kazzuya s Software Driver(gpuKazSoft) 公式サイト：http //web.archive.org/web/20061123075225/http //www.kazzuya.com/test/plugins/ Knack s Soft Driver(gpuNakSoft) 公式サイト：http //www.246.ne.jp/~knack/ Kurimpa 公式サイト：https //github.com/KrossX Lewpy s 3dfx/Glide GPU(gpuLewGlide) 公式サイト：https //web.archive.org/web/20130802175724/http //lewpy.psxemu.com/ 最新版：gpuLewGlide142.zip [NextGL](gpuNextGL) [Next3D](gpuNext3D) [NextSoft](gpuNextSoft) 公式サイト：http //web.archive.org/web/20080324173223/http //nextgl.ngemu.com/ Nik s Direct3D Renderer(gpuNikD3D) ダウンロード：gpunikd3d.zip Null Driver(gpuNull) 公式サイト：http //web.archive.org/web/19990427181519/http //www.psemu.com/ psx emulation cheater(gpupec) ダウンロード：gpupec.zip Pete s OpenGL2 Driver(gpuPeteOpenGL2) 公式サイト：http //www.pbernert.com/index.htm Pete s GPUの苦手とするFramebufferをうまく処理ができ、再現性と美しさを両立している。 Geforce3以降またはRadeon8500以降で64MB以上のVRAMを搭載するローエンドでないビデオカードが必要。 （ただし、オンボードのビデオカードでも快適に動作した例あり。ミドルレンジのGeforce、Radeonでも64bit地雷と呼ばれる廉価品はおすすめできない。） DirectX9に対応しているとなおよい。CPUやメモリもよいものが必要。 デフォルト設定のNICEでは2Dで重いのでNiceからFramebuffer effectsを2にするのがお勧め。 Pete OpenGL2 Tweak 公式サイト：http //dev.tapek.shst.pl/ git https //github.com/Nucleoprotein/PeteOpenGL2Tweak forum http //ngemu.com/threads/peteopengl2tweak-tweaker-for-peteopengl2-plugin-w-gte-accuracy-hack.160319/ Pete s OpenGL2を修正・機能追加したもの。使用するにはPete氏のOpenGL2が必要。 P.E.Op.S. OpenGL Driver(gpuPeopsOpenGL) 公式サイト：http //www.pbernert.com/index.htm Pete s OpenGLがオープンソース化したもの。 Pete s GPU (OpenGL, D3D, DX6) オープンソース化される前(v1.77まで)のもの。 D3D、OpenGLを使っているものは高解像度で美しいがビデオカードを選ぶ。細部の再現が弱いことがある。 ※各プラグインは設定メニューの左下でデフォルト設定が選べるので、そこでNiceを選ぶとよい。 Pete s GPUに含まれるOpenGL、D3D、DX6は再現性はほとんど変わらない。 OpenGL版が、作者さんがメインとして開発しており開発期間が長く最適化も進んでいるため、一番軽く美しい。 Pete s OpenGL：Geforce,Radeon系用。 Pete s D3D：Geforce,Radeon以外ではこれ。オンボードのビデオカードでもCPUが高速ならそこそこ使えることが多い。VRAM最低8MB、推奨16MB以上。 Pete s DX6：D3Dで不具合が出るビデオカード用。(MatroxG400など) Pete s GPUは「熱・水・空間のゆがみ」を表現するために画面に揺らぎを与えるエフェクトが苦手。（Framebufferを使用するエフェクト） P.E.Op.S. Soft Driver(gpuPeopsSoft) 公式サイト：http //www.pbernert.com/index.htm Pete s Soft Driverがオープンソース化したもの。ソフトウェアで描写するためノートPCなどの遅いビデオカードでも問題が少ない。 画像は実機並み。動作が軽い。 再現性が最も高いので、正確な描写を求める場合にもおすすめ。2Dゲームにおすすめ。 Pete s GPUが苦手とするFramebufferの処理でも速度が落ちない。 CPU使用率が常に100%になる問題を解決したPeopsSoftGpu117-for-SSSPSXもある P.E.Op.S. Soft Driver Refresh http //ngemu.com/threads/p-e-op-s-soft-driver-refresh.202433/#post-2689025 上記オリジナルにxBRZなどを追加したもの。 Segu Direct3D Driver(gpuSeguD3d) 公式サイト：https //web.archive.org/web/20130802064233/http //segu.psxemu.com/ Zen OpenGL Driver(gpuZenOpenGL) ダウンロード：gpuZenOpenGL103.zip SPUプラグイン ePSXeであれば特に不具合なければ内蔵プラグインがよい。その他のエミュレータでは Eternal SPU 又は P.E.Op.S. Sound Audio Driver が互換性が高くおすすめ。 DarkMan s SPU Recorder(spuRecorder) 公式サイト：http //web.archive.org/web/20040609200213/http //mrdario.tripod.com/ ダウンロード：recorder20.zip ePSXe内蔵プラグイン 軽い。ePSXe SPU Coreと表示される。ePSXeCutorではInternal ePSXe SPUと表示される。 Eternal SPU Plugin(spuEternal) 公式サイト：http //web.archive.org/web/20050404142854/http //www.psx-alternative.com/ 作者が日本人グループなので詳細な日本語テキストが付属。 お勧め設定は「Audio out method」(音声出力方法)を「spuasync」＋「simpleまたはwait」。waitのほうが互換性が高いが早送りができなくなる。 spuasync+waitはエミュの動作速度をSPUがコントロールするため音ズレが置きにくい。またCPU使用率が常に100%になる問題を解決する。 spuasyncはAdriPSX、PSXevenでは対応してないのでその場合は「Thread」か「Timer」で。 詳しい解説はreadme.txtに日本語で書いてある。 ダウンロード（1.50 beta 2）：spuEternal150beta2.zip Iori s Directound Driver(spuIori) Eternal SPU Pluginの前身 ダウンロード：spuiori148.zip Andy s SPU Audio Driver(spuAndy) Iori s Directound Driverを元に改変を加えたもの ダウンロード：spuAndy_016.zip Kazzuya DirectSound Audio Driver(spuKazDSound) ダウンロード：spukazdsound06.zip 旧版：http //web.archive.org/web/19990427181519/http //www.psemu.com/ No Sound(spuNull) ダウンロード：spunull.zip 旧版：http //web.archive.org/web/19990427181519/http //www.psemu.com/ Null2 s Audio Driver(spuNull2Mixer) 公式サイト：http //web.archive.org/web/20010602204047/http //www.psxemu.com/null/ Null Sound Driver(spuNull7) ダウンロード：spunull7.zip P.E.Op.S. DSound Audio Driver(spuPeopsDSound) 公式サイト：http //www.pbernert.com/index.htm Pete s DSound Audio SPU(spuPeteDSound) P.E.Op.S. DSound Audio Driverの前身 Pete s MIDAS Audio SPU(spuPeteMidas) Pete s DSound Audio SPUの前身 P.E.Op.S. Sound Audio Driver(spuPeopsSound_110b) 公式サイト：http //sourceforge.net/u/peopsspu110/profile/ P.E.Op.S. DSoundを改変したもの P.E.Op.S. Sound Audio Driver(spuPeopsSound_110b) 公式サイト：http //dev.tapek.shst.pl/ 上記110bをさらに改変したもの Prodigy sound driver(spuProdigy) ダウンロード：spuprodigy.zip Seal Audio Driver(spuSeal) 公式サイト：http //web.archive.org/web/19990427181519/http //www.psemu.com/ CDRプラグイン CDドライブの指定を間違えないように。 日本のプレステゲームにはサブチャンネルを使ったプロテクトはないのでどのプラグインでも大抵大丈夫。 Windows2000/XPで制限ユーザの場合はASPIを使用するプラグインを使う。 Windows2000/XPでASPI使用するプラグインを使うときはASPIレイヤーのインストールが必要。 ASPIのインストール方法はOSによって異なるのでダウンロード先の解説をよく読むこと。特にXPでは注意。 このASPIで動作がおかしいときはNeroのwnaspi32.dllをエミュ本体と同じフォルダかシステムフォルダ(XPだとc \windows\system32)においてください。但し、NeroのASPIは制限ユーザでは使えない模様。 ePSXe1.6.0以前、PSXevenではISOファイルが直接起動するのが最も軽いが、CDDAを使ったBGMがでない（ePSXe 1.7.0からCUEシートに対応した）。この場合CDR Moobyを使うか、Daemon Toolsを使う。 SSSPSXではISO起動でもCDDAが鳴る。 CDから起動するよりISOから起動、またはDaemon toolsにISOをマウントしてCDRプラグインで仮想ドライブから読み込むのがおすすめ。CDドライブへのアクセスが遅いと（回転数が早くても最初の読み始めが遅いと問題あり）データの読込みが遅延することでゲームに差しさわりがある場合があるが、ISOにして高速なハードディスクから読み込めばそれを防ぐことができる。 ASPI Driver(cdrASPI) ダウンロード先：http //web.archive.org/web/19990427181519/http //www.psemu.com/ Barrett-Kazzuya CDR Driver(cdrBarrett) ダウンロード先：http //web.archive.org/web/19990427181519/http //www.psemu.com/ DAO Image Driver(cdrDAO) ダウンロード先：http //web.archive.org/web/19990427181519/http //www.psemu.com/ |Zink88| s Disk Image Driver(cdrDiskImage) ダウンロード：cdrdiskimage.zip Duddie s ASPI Driver(cdrDudAspi) ダウンロード先：http //web.archive.org/web/19990427181519/http //www.psemu.com/ edgbla s CDR Plugin ダウンロード先：http //www.emucr.com/search/label/cdrBlade? max-results=12 ePSXe内蔵プラグイン Windows9xならePSXe CDR ASPI core。Windows2000,XPならePSXe CDR WNT/W2K core。 2000/XPでも制限ユーザならASPIのほうを使う。軽い。これでも特に問題ない。 ISO Image Driver(cdrISO) ダウンロード：cdriso.zip Linuzappz Iso Cdr Driver(cdriso) 公式サイト：http //web.archive.org/web/20081216003444/http //linuzappz.pcsx.net/ ISOファイルから起動するプラグイン。GUIが使いにくいcdrmooby2より使いやすいかも。zipに同梱のlibbz2.dllをエミュ本体と同じフォルダにコピーする必要がある。 Mooby2 cd disk image driver(cdrmooby2) 公式サイト：http //web.archive.org/web/20071017013314/http //mooby.psxfanatics.com/ ISOファイルから起動するプラグイン。CDDAの再生も可能。ISOイメージの圧縮ができる。 Null Driver(cdrNull) ダウンロード：cdrnull.zip P.E.Op.S. CDR Driver(cdrPeops) 公式サイト：http //www.pbernert.com/index.htm "Interface"でOSを選び、"Drive"で指定したドライブにプレステのCDを入れた状態で"Try auto-detection"をクリックすれば自動で最適なリードモードを選択してくれる。制限ユーザの場合はOSでW9ｘ ASPIを選ぶ。 SaPu s CD-ROM Plugin(cdrsapu) 公式サイト：http //web.archive.org/web/20031004010022/http //sapu.ngemu.com/ 最新版配布先：http //ngemu.com/threads/new-version-of-cdrsapu-psx-cdrom-plugin-released.116936/ ダウンロード：cdrsapu_v1.3.zip ゲームCDの入ったドライブを自動検出してくれる。互換性も高い。AdriPSXの標準プラグイン Segu ASPI32 Driver(cdrSeguASPI) 公式サイト：https //web.archive.org/web/20130802064233/http //segu.psxemu.com/ SSSPSX CDR Plugin [INTERNAL](内蔵プラグイン) CD起動、ISO起動両対応。ISO起動でもCDDAが鳴る。SSSPSXではおすすめ。しかしWindows98/MEユーザ、2000/XPの制限ユーザでは使用不可。 Tratax ASPI Driver(cdrTrxASPI) ダウンロード：cdrtrxaspi.zip VirusCDR Image Driver(cdrVirus) 公式サイト：http //dev.tapek.shst.pl/ cdrmooby2を改変したもの。エミュレータ本体と同じ階層にSDL.dllが必要。 Xeven s Cdr Driver(cdrXeven) 公式サイト：http //web.archive.org/web/20071031085343/http //batard.psxfanatics.com/ ゲームCDの入ったドライブを自動検出してくれる。互換性も高い。PSXevenの作者が作った PADプラグイン ePSXeでは2.0より使用可、1.9.25以前は使用不可。 パッドと相性の悪いプラグインも存在するので自分のパッドにあったプラグインを選択する。 DInput Keys Driver(padDIKeys) ダウンロード先：http //web.archive.org/web/19990427181519/http //www.psemu.com/ Duddie s DirectInput Mouse Driver(padDudDIMouse) ダウンロード：padduddimouse.zip Dr.Hell s WinMM PAD Driver(padHellMM) 公式サイト：http //drhell.web.fc2.com/ DirectInputを使わないのでどのパッドでも動きやすい。作者が日本人なので日本語テキスト付属。 Harakiri Pad Plugin(padHarakiri) 公式サイト：http //www.geocities.co.jp/Playtown-Rook/2087/ 一番設定が豊富。振動への対応も一番。作者が日本人なので日本語解説が付属。 Kazzuya GamePad DInput Driver(padKazDInput) ダウンロード：padkazdinput.zip Keyboard Driver(padkey) ダウンロード：padkey.zip N-Rage Plugin(padNRagePlugin) Nintendo64エミュのPADプラグインと共通(Version 0.95まで？) ダウンロード：padnrageplugin.zip Null Driver(padNull) ダウンロード先：http //web.archive.org/web/19990427181519/http //www.psemu.com/ nuvee psx pad(nuvee_psx_pad) ダウンロード先：http //ngemu.com/threads/input-plugin-nuvee-psx-controller.143143/ pad Gnneco [en, DI7](padGnneco) 公式サイト：http //web.archive.org/web/20090216185450/http //members.at.infoseek.co.jp/shirouto_yokota/pgnneco.htm ネジコンが使える Pokopom XInput Pad Plugin(padPokopom) 公式サイト：https //github.com/KrossX Emulates a DualShock and DualShock2 for PSX and PS2 emus respectively. Extended analog range on edges, for games like Ape Escape. Supports rumble with a nice custom curve. Scroll Lock key as analog toggle and LED. Pseudo "pressure" for a smooth transition between off and fully pressed. Segu Direct Input Joystick(padSeguDIJoy) Segu Direct Input Keyboard(padSeguDIKey) Segu Direct Pad Pro Driver(padSeguDPP) 公式サイト：https //web.archive.org/web/20130802064233/http //segu.psxemu.com/ SSSPSX PAD Plugin(PadSSSPSX) 公式サイト：http //web.archive.org/web/20070714104459/http //www.ssspsx.com/ SSSPSXの作者が作った。PS2エミュでも使える。パッドを2つ設定すると不具合が起こる場合があるのは ver1.7で直った。 SSSPSX PAD Plugin Zeta(PadSSSPSX (Z)) SSSPSX PAD PluginをEternal SPUの作者であるT.Yano氏が改変したもの。 ダウンロード：SSSPSXPAD-Zeta-2006-09-07.zip SSSPSX PAD Plugin Pressure Mod(PadSSSPSX Pressure Mod) SSSPSX PAD PluginをPCSX2 Teamが改変したもの。 公式SVN snapshot：http //buildbot.orphis.net/pcsx2/ pcsx2-xxxx-windows-x86\pluginsの中に入っている。 TwinPad(padTwinPad) ダウンロード先：http //forums.pcsx2.net/Thread-TwinPad-v0-8-3 NetPlayプラグイン 導入することで通信対戦が可能。 CyberPad(cpka) 公式サイト：http //cyberpad.duttke.de/ netSock(netSock) ダウンロード先：https //web.archive.org/web/20120126205104/http //www.pcsx.net/downloads/plugins/ PS4NET 公式サイト：http //web.archive.org/web/20070604183724/http //an.sakura.ne.jp/~know/ps4net/
https://w.atwiki.jp/usb_audio/pages/19.html
原文：Audio Devices Rev. 2.0 Spec and Adopters Agreement(ZIP) USB Device Class Definition for Audio Devices Release 2.0 Release 2.0 May 31, 2006 May 31, 2006 1 Universal Serial Bus Device Class Definition for Audio Devices USB Device Class Definition for Audio Devices Release 2.0 May 31, 2006 2 Scope of This Release This document is the Release 2.0 of this device class definition. Contributors Geert Knapen (Editor) Philips Applied Technologies AppTech-USA 1101 McKay Drive M/S 16 San Jose, CA 95131 USA Phone +1 (408) 474-8774 E-mail geert.knapen(at)philips.com Mike Kent Roland Corporation Kaoru Ishimine Roland Corporation Shoichi Kojima Roland Corporation Robert Gilsdorf Creative Labs Daniel (D.J.) Sisolak Microsoft Corporation Jack Unverferth Microsoft Corporation Niel Warren Apple Computer, Inc. Len Layton C-Media Electronics Mark Cookson M-Audio Revision History Revision Date Filename Author Description 1.7 Sep. 3, 02 Audio17.doc USB-IF DWG Initial version. Based on Audio10.doc. This version will be used to capture the areas where the spec needs adjustments. Areas are indicated by comments. 1.7a Oct. 24, 02 Audio17a.doc Geert Knapen Areas are identified where changes need to be made. Some minor changes already introduced. 1.7b Oct. 24, 02 Audio17b.doc Geert Knapen Intermediate version 1.7c Dec. 10, 02 Audio17c.doc Geert Knapen Discussions from 12-18-2002 f2f meeting captured. Additional comments added. 1.7d Feb. 3, 03 Audio17d.doc Geert Knapen Changes from 1.7c accepted. Additional changes introduced. 1.7e Feb. 19, 03 Audio17e.doc Geert Knapen Introduced physical vs. logical channel cluster 1.7f Feb. 19, 03 Audio17f.doc Geert Knapen Accepted all changes in 1.7e. Fixed some typos. 1.7g Jun. 2, 03 Audio17g.doc Geert Knapen Major overhaul with the introduction of the RANGE attribute. 1.7h Jun. 3, 03 Audio17h.doc Geert Knapen Accepted all changes USB Device Class Definition for Audio Devices Release 2.0 May 31, 2006 3 Revision Date Filename Author Description 1.7i Jul. 10, 03 Audio17i.doc Geert Knapen Introduced clock domain, interface association descriptor 1.7j Jul. 10, 03 Audio17j.doc Geert Knapen Accepted all changes 1.7k Sep. 8, 03 Audio17k.doc Geert Knapen Introduced Function Subclass codes, extended interrupt usage, cleaned up clock domains and removed clock domain group concept. Replaced by Clock Source Entity. 1.7l Sep. 10, 03 Audio17l.doc Geert Knapen Accepted all the changes 1.7m Sep. 15, 03 Audio17m.doc Geert Knapen Cleaned up Interrupt description 1.7n Sep. 30, 03 Audio17n.doc Geert Knapen Accepted all changes 1.7o Sep. 30, 03 Audio17o.doc Geert Knapen Major rewrite w.r.t. Controls. 1.7p Nov. 05, 03 Audio17p.doc Geert Knapen Accepted all the changes. Added bit pairs for indicating Control availability 1.7q Nov. 07, 03 Audio17q.doc Geert Knapen Introduced the new concept of controlling sampling frequency 1.7r Dec. 01, 03 Audio17r.doc Geert Knapen Accepted all the changes 1.7s Dec. 10, 03 Audio17s.doc Geert Knapen Changed physical-logical cluster mapping. Added explanation on binding between physical buttons and Audio Controls 1.7t Feb. 04, 04 Audio17t.doc Geert Knapen Accepted all changes 1.7u Feb. 05, 04 Audio17u.doc Geert Knapen Introduced Effect Unit. Regrouped some PUs into the EU concept. Added Parametric EQ as an EU. Accepted all changes 1.7v Mar. 30, 04 Audio17v.doc Geert Knapen Full proof-read. Changed formatting and wording throughout the document 1.7w Mar. 30, 04 Audio17w.doc Geert Knapen Accepted all the changes. Added new Function Categories. Added physical cluster desctriptor to AS interface descriptor. 1.7x Apr. 13, 04 Audio17x.doc Geert Knapen Accepted all the changes. Added new Function Categories. Added support for encoders and decoders. 1.7y Apr. 28, 04 Audio17y.doc Geert Knapen Accepted all the changes. 1.7z May 15, 04 Audio17z.doc Geert Knapen Added some fields to encoder descriptors. 1.8 May 26, 04 Audio18.doc Geert Knapen Accepted all changes and promoted to 1.8 level USB Device Class Definition for Audio Devices Release 2.0 May 31, 2006 4 Revision Date Filename Author Description 1.8a Sep. 15, 04 Audio18a.doc Geert Knapen Corrected some errors in table offsets etc as indicated by Len Layton (CMedia) Identified the need to address ASR converter Unit 1.8b Mar. 15, 05 Audio18b.doc Geert Knapen Minor editorial changes 1.8c Aug. 10, 05 Audio18c.doc Geert Knapen Minor editorial changes 1.8d Aug. 16, 05 Audio18d.doc Geert Knapen Accepted editorial changes, based on F2F meeting review. Added and accepted an ID field for all encoder and decoder descriptors. This ID must also be passed into the requests that address the encoder or decoder. 1.8e Aug. 17, 05 Audio18e.doc Geert Knapen Redid the encoder sections. Added generic latency support. Added SRC Unit. 1.8f Aug. 31, 05 Audio18f.doc Geert Knapen Fixed some heading levels. Added DTS. 1.8g Sep. 02, 05 Audio18g.doc Geert Knapen Added Encoder and Decoder Error Codes. Accepted all the changes. 1.9RC1 Sep. 02, 05 Audio19RC1.doc Geert Knapen Republished unchanged as 1.9RC1. 1.9RC2 Oct. 05, 05 Audio19RC2.doc Geert Knapen Made several small editorial changes. Accepted all the changes. 1.9 Oct. 07, 05 Audio19.doc Geert Knapen Promoted to 1.9 without change. 2.0RC1 May 19, 06 Audio20RC1.doc Geert Knapen Addressed and accepted some minor changes. Declared this document as the Release Candidate for the 2.0 version. 2.0 May 31, 06 Audio20.doc Geert Knapen Added new Intellectual Property Disclaimer. Final version. USB Device Class Definition for Audio Devices Release 2.0 May 31, 2006 5 Copyright © 1997-2006 USB Implementers Forum, Inc. All rights reserved. INTELLECTUAL PROPERTY DISCLAIMER A LICENSE IS HEREBY GRANTED TO REPRODUCE THIS SPECIFICATION FOR INTERNAL USE ONLY. NO OTHER LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED OR INTENDED HEREBY. USB-IF AND THE AUTHORS OF THIS SPECIFICATION EXPRESSLY DISCLAIM ALL LIABILITY FOR INFRINGEMENT OF INTELLECTUAL PROPERTY RIGHTS RELATING TO IMPLEMENTATION OF INFORMATION IN THIS SPECIFICATION. USB-IF AND THE AUTHORS OF THIS SPECIFICATION ALSO DO NOT WARRANT OR REPRESENT THAT SUCH IMPLEMENTATION(S) WILL NOT INFRINGE THE INTELLECTUAL PROPERTY RIGHTS OF OTHERS. THIS SPECIFICATION IS PROVIDED “AS IS” AND WITH NO WARRANTIES, EXPRESS OR IMPLIED, STATUTORY OR OTHERWISE. ALL WARRANTIES ARE EXPRESSLY DISCLAIMED. USB-IF, ITS MEMBERS AND THE AUTHORS OF THIS SPECIFICATION PROVIDE NO WARRANTY OF MERCHANTABILITY, NO WARRANTY OF NON-INFRINGEMENT, NO WARRANTY OF FITNESS FOR ANY PARTICULAR PURPOSE, AND NO WARRANTY ARISING OUT OF ANY PROPOSAL, SPECIFICATION, OR SAMPLE. IN NO EVENT WILL USB-IF, MEMBERS OR THE AUTHORS BE LIABLE TO ANOTHER FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA OR ANY INCIDENTAL, CONSEQUENTIAL, INDIRECT, OR SPECIAL DAMAGES, WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THE USE OF THIS SPECIFICATION, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. NOTE VARIOUS USB-IF MEMBERS PARTICIPATED IN THE DRAFTING OF THIS SPECIFICATION. CERTAIN OF THESE MEMBERS MAY HAVE DECLINED TO ENTER INTO A SPECIFIC AGREEMENT LICENSING INTELLECTUAL PROPERTY RIGHTS THAT MAY BE INFRINGED IN THE IMPLEMENTATION OF THIS SPECIFICATION. PERSONS IMPLEMENT THIS SPECIFICATION AT THEIR OWN RISK. Dolby™, AC-3™, Pro Logic™ and Dolby Surround™ are trademarks of Dolby Laboratories, Inc. All other product names are trademarks, registered trademarks, or service marks of their respective owners. Please send comments via electronic mail to audio-chair(at)usb.org 1 - 6 - 11 - 16 - 21 - 26 - 31 - 36 - 41 - 46 - 51 - 56 - 61 - 66 - 71 - 76 - 81 - 86 - 91 - 96 - 101 - 106 - 111 - 116 - 121 - 126 - 131 - 136 - 141 ここを編集
https://w.atwiki.jp/usb_audio/pages/60.html
原文：Audio Devices Rev. 2.0 Spec and Adopters Agreement(ZIP) Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 1 Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 2 Scope of This Release This document is the Release 2.0 of this device class definition. Contributors Geert Knapen (Editor) Philips Applied Technologies AppTech-USA 1101 McKay Drive M/S 16 San Jose, CA 95131 USA Phone +1 (408) 474-8774 E-mail geert.knapen(at)philips.com Mike Kent Roland Corporation Kaoru Ishimine Roland Corporation Shoichi Kojima Roland Corporation Robert Gilsdorf Creative Labs Daniel (D.J.) Sisolak Microsoft Corporation Jack Unverferth Microsoft Corporation Niel Warren Apple Computer, Inc. Len Layton C-Media Electronics Mark Cookson M-Audio Revision History Revision Date Filename Author Description 1.7 Mar 18, 98 Frmts17.doc USB-IF DWG Original Frmts.doc document opened for review. 1.7a Oct. 24, 02 Frmts17a.doc Geert Knapen Identified areas for change. 1.7b Dec 06, 02 Frmts17b.doc DJ Sisolak Updated for USB 2.0 Core Specification 1.7c Dec 10, 02 Frmts17c.doc DJ Sisolak Make comments on the edits and accepted a number of changes. 1.7d Feb. 05, 03 Frmts17d.doc Geert Knapen Reviewed and accepted additional changes. 1.7e Feb. 07, 03 Frmts17e.doc Geert Knapen Completed cluster descriptors in Format descriptors. Added language for the sliding averaging window. 1.7e1 Feb. 19, 03 Frmts17e1.doc Geert Knapen Actually added language for USB packetization. 1.7f Mar. 26, 03 Frmts17f.doc Geert Knapen Accepted all changes 1.7g Apr. 07, 03 Frmts17g.doc Geert Knapen Major overhaul. Halfway through the RANGE implementation 1.7h Jun. 03, 03 Frmts17h.doc Geert Knapen Accepted all the changes so far. 1.7i Jun. 03, 03 Frmts17i.doc Geert Knapen Edited requests to reflect the RANGE attribute Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 3 Revision Date Filename Author Description 1.7j Jul..11, 03 Frmts1ji.doc Geert Knapen Accepted all the changes, fixed a duplicate definition for D6 1.7k Sep. 08, 03 Frmts17k.doc Geert Knapen Added RAW_DATA format 1.7l Sep. 10, 03 Frmts17l.doc Geert Knapen Accepted all the changes 1.7m Oct. 14, 03 Frmts17m.doc Geert Knapen Added CN to all requests. Added some Controls. 1.7n Nov. 05, 03 Frmts17n.doc Geert Knapen Accepted all the changes. 1.7o Nov. 17, 03 Frmts17o.doc Geert Knapen Removed all references to sampling frequencies in the format-specific descriptors. 1.7p Dec. 01, 03 Frmts17p.doc Geert Knapen Accepted all the changes 1.7q Dec. 12, 03 Frmts17q.doc Geert Knapen Introduced extended Format Types 1.7r Feb. 04, 04 Frmts17r.doc Geert Knapen Accepted all changes 1.7s Apr. 13, 04 Frmts17s.doc Geert Knapen Added new Type III codes. Added Hi-Res Timestamp Sideband Protocol. Added Type IV Format. Moved decoder information to Audio document. Removed the concept of Format-specific descriptors and replaced them with Decoder descriptors 1.7t Apr. 28, 04 Frmts17t.doc Geert Knapen Added more info on the different audio data format types. 1.8 May 26, 04 Frmts18.doc Geert Knapen Accepted all changes and promoted to 1.8 level. 1.8a Aug. 10, 05 Frmts18a.doc Geert Knapen Minor editorial changes 1.8b Aug. 16, 05 Frmts18b.doc Geert Knapen Accepted editorial changes, based on F2F meeting review 1.8c Aug. 16, 05 Frmts18c.doc Geert Knapen Added DTS support 1.8d Sep. 02, 05 Frmts18d.doc Geert Knapen Accepted all the changes. 1.9RC1 Sep. 02, 05 Frmts19RC1.doc Geert Knapen Republished unchanged as 1.9RC1 1.9RC2 Oct. 05, 05 Frmts19RC2.doc Geert Knapen Removed comment on the Microsoft link. Accepted the change. 1.9 Oct. 07, 05 Frmts19.doc Geert Knapen Promoted to 1.9 without change. 2.0RC1 May 19, 06 Frmts20RC1.doc Geert Knapen Promoted to 2.0RC1 without change. Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 4 Revision Date Filename Author Description 2.0 May 31, 06 Frmts20.doc Geert Knapen Added new Intellectual Property Disclaimer. Final version. Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 5 Copyright © 1997-2006 USB Implementers Forum, Inc.All rights reserved. INTELLECTUAL PROPERTY DISCLAIMER A LICENSE IS HEREBY GRANTED TO REPRODUCE THIS SPECIFICATION FOR INTERNAL USE ONLY. NO OTHER LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED OR INTENDED HEREBY. USB-IF AND THE AUTHORS OF THIS SPECIFICATION EXPRESSLY DISCLAIM ALL LIABILITY FOR INFRINGEMENT OF INTELLECTUAL PROPERTY RIGHTS RELATING TO IMPLEMENTATION OF INFORMATION IN THIS SPECIFICATION. USB-IF AND THE AUTHORS OF THIS SPECIFICATION ALSO DO NOT WARRANT OR REPRESENT THAT SUCH IMPLEMENTATION(S) WILL NOT INFRINGE THE INTELLECTUAL PROPERTY RIGHTS OF OTHERS. THIS SPECIFICATION IS PROVIDED “AS IS” AND WITH NO WARRANTIES, EXPRESS OR IMPLIED, STATUTORY OR OTHERWISE. ALL WARRANTIES ARE EXPRESSLY DISCLAIMED. USB-IF, ITS MEMBERS AND THE AUTHORS OF THIS SPECIFICATION PROVIDE NO WARRANTY OF MERCHANTABILITY, NO WARRANTY OF NON-INFRINGEMENT, NO WARRANTY OF FITNESS FOR ANY PARTICULAR PURPOSE, AND NO WARRANTY ARISING OUT OF ANY PROPOSAL, SPECIFICATION, OR SAMPLE. IN NO EVENT WILL USB-IF, MEMBERS OR THE AUTHORS BE LIABLE TO ANOTHER FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA OR ANY INCIDENTAL, CONSEQUENTIAL, INDIRECT, OR SPECIAL DAMAGES, WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THE USE OF THIS SPECIFICATION, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. NOTE VARIOUS USB-IF MEMBERS PARTICIPATED IN THE DRAFTING OF THIS SPECIFICATION. CERTAIN OF THESE MEMBERS MAY HAVE DECLINED TO ENTER INTO A SPECIFIC AGREEMENT LICENSING INTELLECTUAL PROPERTY RIGHTS THAT MAY BE INFRINGED IN THE IMPLEMENTATION OF THIS SPECIFICATION. PERSONS IMPLEMENT THIS SPECIFICATION AT THEIR OWN RISK. Dolby™, AC-3™, Pro Logic™ and Dolby Surround™ are trademarks of Dolby Laboratories, Inc. All other product names are trademarks, registered trademarks, or service marks of their respective owners. Please send comments via electronic mail to audio-chair(atusb.org) 1 - 6 - 11 - 16 - 21 - 26 - 31 ここを編集
https://w.atwiki.jp/usb_audio/pages/14.html
原文：Audio Device Document 1.0(PDF) USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 i Universal Serial Bus Device Class Definition for Audio Devices Release 1.0 March 18, 1998 USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 ii Scope of This Release This document is the 1.0 release of this device class definition. Contributors Gal AshourIBM Corporation Billy BrackenridgeMicrosoft Corporation Oren TiroshAltec Lansing Craig ToddDolby Laboratories Remy ZimmermannLogitech Geert KnapenPhilips ITCL Interleuvenlaan 74-76 B-3001 Leuven-Heverlee BELGIUM Phone +32 16 390 734 Fax +32 16 390 600 E-mail Geert.Knapen(at)innet.be Revision History Revision Date Filename Author Description 0.1 Aug. 7, 95 Audio01.doc Geert Knapen Initial version. 0.2 Aug. 28, 95 Audio01.doc Geert Knapen Corrected typos.Attributes field from 8 to 16 bits.Auxiliary channel definition.Important issues added. 0.3 Oct. 9, 95 Audio03.doc Geert Knapen Intermediate version. 0.4 Nov. 29, 95 Audio04.doc Geert Knapen Change to Audio Function and Interface Property requests.Synch issues updated.Subclass divisions changed. 0.6 Dec. 19, 95 Audio06.doc Geert Knapen Listed remarks from last f2f Dec 7-8. 0.8 Dec. 12, 95 Audio08.doc Geert Knapen Incorporated changes, discussed at f2f Dec 6 95. 0.8a Jan. 20, 96 Audio08a.doc Geert Knapen Incorporated changes discussed at f2f Jan 18 95.Feedforward/feedback endpoint is now called synch endpoint. Feb. 5, 96 usb_au8a.doc Edited version of Audio08a.doc. 0.8b June. 5, 96 Audio08b.doc Geert Knapen Introduced new mixer concepts etc. 0.8c Oct. 1, 96 Audio08c.doc Geert Knapen Added appropriate descriptors and requests. 0.8d Dec. 1, 96 Audio08d.doc Geert Knapen Included remarks on 0.8c USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 iii Revision Date Filename Author Description 0.8e Jan. 1, 97 Audio08e.doc Geert Knapen Included remarks on 0.8d. Added Dolby Prologic and Up/Down-mix Processing Units. 0.8f Mar. 1, 97 Audio08f.doc Geert Knapen Removed associated interface. Added Set/Get Memory requests for all Entities. Introduced copyright protection, Audio Interface Collections. Added Stereo Widening Processing Unit. Added Reverb Processing Unit. Added Chorus Unit. Added Bass Boost and Loudness Controls. 0.9rc Apr. 1, 97 Audio09rc.doc Geert Knapen Changed Section 5 structure. Removed many request codes. Added requests for Reverb and Chorus. Changed Terminal request structure. Included all remarks from last meeting. 0.9 May 1, 97 Audio09.doc Geert Knapen Added wLockDelay and bLockUnits fields to CS endpoint descriptor. Added bit to CS endpoint descriptor to indicate packet size restrictions. Revised endpoint descriptors according to new CCS layout. Added Dynamic Range Compressor PU. 0.9CE Sep 1, 97 Audio09CE.doc Geert Knapen Copy-edited for publication on the web. 0.9a Oct 1, 97 Audio09a.doc Geert Knapen Incorporated RRs 1.0RC Mar 1, 98 Audio10RC.doc Geert Knapen Added examples and cleaned up the formatting. 1.0 Mar 18, 98 Audio10.doc Geert Knapen Changed all references to 1.0. USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 iv Copyright © 1997, USB Implementers ForumAll rights reserved. INTELLECTUAL PROPERTY DISCLAIMER THIS SPECIFICATION IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER INCLUDING ANY WARRANTY OF MERCHANTABILITY, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION, OR SAMPLE. A LICENSE IS HEREBY GRANTED TO REPRODUCE AND DISTRIBUTE THIS SPECIFICATION FOR INTERNAL USE ONLY. NO OTHER LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY OTHER INTELLECTUAL PROPERTY RIGHTS IS GRANTED OR INTENDED HEREBY. AUTHORS OF THIS SPECIFICATION DISCLAIM ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF PROPRIETARY RIGHTS, RELATING TO IMPLEMENTATION OF INFORMATION IN THIS SPECIFICATION. AUTHORS OF THIS SPECIFICATION ALSO DO NOT WARRANT OR REPRESENT THAT SUCH IMPLEMENTATION(S) WILL NOT INFRINGE SUCH RIGHTS. Dolby™, AC-3™, Pro Logic™ and Dolby Surround™ are trademarks of Dolby Laboratories, Inc. All other product names are trademarks, registered trademarks, or service marks of their respective owners. Please send comments via electronic mail to techsup(atusb.org) USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 v Table of Contents Scope of This Release.........................................................................................................ii Contributors........................................................................................................................ii Revision History ..................................................................................................................ii Table of Contents ................................................................................................................v List of Tables ....................................................................................................................viii List of Figures...................................................................................................................xiii 1 Introduction ................................................................................................................14 1.1 Scope....................................................................................................................14 1.2 Purpose .................................................................................................................14 1.3 Related Documents ...............................................................................................14 1.4 Terms and Abbreviations.......................................................................................14 2 Management Overview...............................................................................................17 3 Functional Characteristics.........................................................................................18 3.1 Audio Interface Class.............................................................................................18 3.2 Audio Interface Subclass and Protocol...................................................................18 3.3 Audio Synchronization Types.................................................................................19 3.3.1 Asynchronous .................................................................................................19 3.3.2 Synchronous...................................................................................................19 3.3.3 Adaptive .........................................................................................................19 3.4 Inter Channel Synchronization ...............................................................................19 3.5 Audio Function Topology .......................................................................................20 3.5.1 Input Terminal ................................................................................................21 3.5.2 Output Terminal..............................................................................................21 3.5.3 Mixer Unit .......................................................................................................22 3.5.4 Selector Unit...................................................................................................22 3.5.5 Feature Unit....................................................................................................23 3.5.6 Processing Unit...............................................................................................23 3.5.7 Extension Unit ................................................................................................28 3.5.8 Associated Interfaces......................................................................................28 3.6 Copy Protection .....................................................................................................28 3.7 Operational Model .................................................................................................29 3.7.1 AudioControl Interface ....................................................................................30 3.7.2 AudioStreaming Interface ...............................................................................31 4 Descriptors .................................................................................................................36 4.1 Device Descriptor ..................................................................................................36 4.2 Configuration Descriptor ........................................................................................36 4.3 AudioControl Interface Descriptors.........................................................................36 4.3.1 Standard AC Interface Descriptor....................................................................36 4.3.2 Class-Specific AC Interface Descriptor ...........................................................37 4.4 AudioControl Endpoint Descriptors ........................................................................57 1 - 6 - 11 - 16 - 21 - 26 - 31 - 36 - 41 - 46 - 51 - 56 - 61 - 66 - 71 - 76 - 81 - 86 - 91 - 96 - 101 - 106 - 111 - 116 - 121 - 126 ここを編集
https://w.atwiki.jp/usb_audio/pages/62.html
原文：Audio Devices Rev. 2.0 Spec and Adopters Agreement(ZIP) Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 11 2 Audio Data Formats Audio Data formats can be divided in two main groups • Simple Audio Data Formats • Extended Audio Data Formats Simple Audio Data Formats can then be subdivided into four groups according to type. The first group, Type I, deals with audio data streams that are transmitted over USB and are constructed on a sample-by-sample basis. Each audio sample is represented by a single independent symbol, contained in an audio subslot. Different compression schemes may be used to transform the audio samples into symbols. Note This is different from encoding. Compression is considered to take place on a per-audio-sample base. Each audio sample generates one symbol (e.g. A-law compression where a 16-bit audio sample is compressed into an 8 bit symbol). If multiple physical audio channels are formatted into a single audio channel cluster, then samples at time x of subsequent channels are first contained into audio subslots. These audio subslots are then interleaved, according to the cluster channel ordering as described in the main USB Audio Specification, and then grouped into an audio slot. The audio samples, taken at time x+1, are interleaved in the same fashion to generate the next audio slot and so on. The notion of physical channels is explicitly preserved during transmission. A typical example of Type I formats is the standard PCM audio data. The following figure illustrates the concept. ここに画像 Figure 2-1 Type I Audio Stream The second group, Type II, deals with those formats that do not preserve the notion of physical channels during the transmission over USB. Typically, all non-PCM encoded audio data streams belong to this group. A number of audio samples, often originating from multiple physical channels and taken over a certain period of time, are encoded into a number of bits in such a way that, after transmission, the original audio samples can be reconstructed to a certain degree of accuracy. The number of bits used for transmission is typically one or more orders of magnitude smaller than the number of bits needed to represent the original PCM audio samples, effectively realizing a considerable bandwidth reduction during transmission. Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 12 ここに画像 Figure 2-2 Type II Audio Stream The third group, Type III, contains special formats that do not fit in both previous groups. In fact, they mix characteristics of Type I and Type II groups to transmit audio data streams over USB. One or more non-PCM encoded audio data streams are packed into “pseudo-stereo samples” and transmitted as if they were real stereo PCM audio samples. The sampling frequency of these pseudo samples matches the sampling frequency of the original PCM audio data streams. Therefore, clock recovery at the receiving end is easier than it is in the case of Type II formats. The drawback is that unless multiple non-PCM encoded streams are packed into one pseudo stereo stream, more bandwidth than necessary is consumed. The fourth group, Type IV, deals with audio streams that are not transmitted over USB. Instead, they interface with the audio function through an AudioStreaming interface that does not contain a USB isochronous IN or OUT endpoint. These streams typically connect via a digital interface like S/PDIF (or some other means of connectivity) but require interaction from the Host before they enter or leave the audio function. A typical example is an external S/PDIF connector that can accept an AC-3 encoded audio stream. This stream is first processed by an AC-3 decoder before the (decoded) logical audio channels enter the audio function through the Input Terminal that represents this S/PDIF connection. The capabilities of the AC-3 decoder are advertised by means of the AC-3 Decoder descriptor and the decoder Controls can be programmed through the AudioStreaming interface. In addition to the Simple Audio Data Formats described above, Extended Audio Data Formats are defined. These are based on the Simple Audio Data Formats Type I, II, and III definitions but they provide an optional packet header and for the Extended Audio Data Format Type I, an optional synchronous (i.e. sample accurate) control channel. Type IV Audio Data Formats do not have an Extended Audio Data Format definition. Section A.1, “Format Type Codes” summarizes the Audio Data Formats that are currently supported by the Audio Device Class. The following sections explain those formats in more detail. 2.1 Transfer Delimiter Isochronous data streams are continuous in nature, although the actual number of bytes sent per packet may vary throughout the lifetime of the stream (for rate adaptation purposes for instance). To indicate a temporary stop in the isochronous data stream without closing the pipe (and thus relinquishing the USB Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 13 bandwidth), an in-band Transfer Delimiter needs to be defined. This specification considers two situations to be a Transfer Delimiter. The first is a zero-length data packet and the second is the absence of an isochronous transfer in a USB (micro)frame that would normally have an isochronous transfer. Both situations are considered equivalent and the audio function is expected to behave the same. However, the second type consumes less isochronous USB bandwidth (i.e. zero bandwidth). In both cases, this specification considers a Transfer Delimiter to be an entity that can be sent over the USB. 2.2 Virtual Frame and Virtual Frame Packet Definitions To better describe packetization for audio the concept of a “virtual frame” (VF) is introduced. A virtual frame is defined as VF = (micro)frame * 2(bInterval-1) In addition, a “virtual frame packet” (VFP) is introduced. A virtual frame packet is defined as a packet that contains all the samples that are transferred over the bus during a virtual frame. For full-/high-speed endpoints, the virtual frame packets are exactly the same as the physical packets that are transferred over USB. However, for high-speed high-bandwidth endpoints, the virtual frame packet is the concatenation of the two or three physical packets that are transferred over the bus in a microframe. Note The USB Specification already considers the 2 or 3 transactions of a high-speed high-bandwidth transfer to be part of a single packet. See Section 5.12.3, “Clock Synchronization” The above definitions provide a model of ‘one (virtual frame) packet per (virtual) frame’, irrespective of the actual transactions on the USB. 2.3 Simple Audio Data Formats 2.3.1 Type I Formats The following sections describe the Audio Data Formats that belong to Type I. A number of terms and their definition are presented. 2.3.1.1 USB Packets Audio data streams that are inherently continuous must be packetized when sent over the USB. The quality of the packetizing algorithm directly influences the amount of effort needed to reconstruct a reliable sample clock at the receiving side. The goal must be to keep the instantaneous number of audio slots per virtual frame, ni as close as possible to the average number of audio slots per virtual frame, nav. The average nav must be calculated as follows ここに数式 where TVF is the duration of a virtual frame and Δt is the sample time (1/FS). In most cases nav will be a number with a fractional part. If the sampling rate is a constant, the allowable variation on ni is limited to one audio slot, that is, Δni = 1. This implies that all virtual frame packets must either contain INT(nav ) audio slots (small VFP) or INT(nav) + 1 (large VFP) audio slots. For all i ni = INT(nav) | INT(nav) + 1 Note In the case where nav = INT(nav), ni may vary between INT(nav) - 1 (small VFP), INT(nav) (medium VFP) and INT(nav) + 1 (large VFP). Furthermore, a large VFP must be generated as soon as it becomes available. Typically, a source will generate a number of small VFPs as long as the accumulated fractional part of nav remains 1. Once the Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 14 accumulated fractional part of nav becomes ≥ 1, the source must send a large VFP and decrement the accumulator by 1. Due to possible different notions of time in the source and the sink (they might each have their own independent sampling clock), the (small VFP)/(large VFP) pattern generated by the source may be different from what the sink expects. Therefore, the sink must be capable to accept a large VFP at all times. Example Assume FS = 44,100 Hz and TVF = 1ms. Then nav = 44.1 audio slots. Since the source can only send an integer number of audio slots per VF, it will send small VFPs of 44 audio slots. Each VF, it therefore sends ‘0.1 slot’ too few and it will accumulate this fractional part in an accumulator. After having sent 9 small VFPs of 44 audio slots, at the tenth VF it will have exactly one audio slot in excess and therefore can send a large VFP containing 45 audio slots. Decrementing the accumulator by 1 brings it back to 0 and the process can start all over again. The source will thus produce a repetitive pattern of 9 small VFPs of 44 audio slots followed by 1 large VFP of 45 audio slots. The following table illustrates the process Table 2-1 Packetization #VF nav ni Fraction Accumulator n 44.1 44 0.1 0.1 n+1 44.1 44 0.1 0.2 n+2 44.1 44 0.1 0.3 n+3 44.1 44 0.1 0.4 n+4 44.1 44 0.1 0.5 n+5 44.1 44 0.1 0.6 n+6 44.1 44 0.1 0.7 n+7 44.1 44 0.1 0.8 n+8 44.1 44 0.1 0.9 n+9 44.1 45 0.1 1.0 - 0 n+10 44.1 44 0.1 0.1 n+11 44.1 44 0.1 0.2 … … … … … *原文は枠線無し 2.3.1.2 Pitch Control If the sampling rate can be varied (to implement pitch control), the allowable variation on ni is limited to one audio slot per virtual frame. For all i ni+1 = ni | ni ± 1 Pitch control is restricted to adaptive endpoints only. AudioStreaming interfaces that support pitch control on their isochronous endpoint are required to report this in the class-specific endpoint descriptor. In addition, a Set/Get Pitch Control request is required to enable or disable the pitch control functionality. Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 15 2.3.1.3 Audio Subslot The basic structure used to represent audio data is the audio subslot. An audio subslot holds a single audio sample. An audio subslot always contains an integer number of bytes. This specification limits the possible audio subslot sizes (bSubslotSize) to 1, 2, 3 or 4 bytes per audio subslot. An audio sample is represented using a number of bits (bBitResolution) less than or equal to the total number of bits available in the audio subslot, i.e. bBitResolution ≤ bSubslotSize*8. AudioStreaming endpoints must be constructed in such a way that a valid transfer can take place as long as the reported audio subslot size (bSubslotSize) is respected during transmission. If the reported bits per sample (bBitResolution) do not correspond with the number of significant bits actually used during transfer, the device will either discard trailing significant bits ([actual_bits_per_sample] bBitResolution) or interpret trailing zeros as significant bits ([actual_bits_per_sample] bBitResolution). 2.3.1.4 Audio Slot An audio slot consists of a collection of audio subslots, each containing an audio sample of a different physical audio channel, taken at the same moment in time. The number of audio subslots in an audio slot equals the number of logical audio channels in the audio channel cluster. The ordering of the audio subslots in the audio slot obeys the rules set forth in the USB Audio Specification. All audio subslots must have the same audio subslot size. 2.3.1.5 Audio Streams An audio stream is a concatenation of a potentially very large number of audio slots, ordered according to ascending time. Streams are packetized when transported over USB whereby virtual frame packets can only contain an integer number of audio slots. Each packet always starts with the same channel, and the channel order is respected throughout the entire transmission. If, for any reason, there are no audio slots available to construct a VFP, a Transfer Delimiter must be sent instead. 2.3.1.6 Type I Format Type Descriptor The Type I format type descriptor starts with the usual three fields bLength, bDescriptorType, and bDescriptorSubtype. The bFormatType field indicates this is a Type I descriptor. The bSubslotSize field indicates how many bytes are used to transport an audio subslot. The bBitResolution field indicates how many bits of the total number of available bits in the audio subslot are truly used by the audio function to convey audio information. Table 2-2 Type I Format Type Descriptor Offset Field Size Value Description 0 bLength 1 Number Size of this descriptor, in bytes 6 1 bDescriptorType 1 Constant CS_INTERFACE descriptor type. 2 bDescriptorSubtype 1 Constant FORMAT_TYPE descriptor subtype. 3 bFormatType 1 Constant FORMAT_TYPE_I. Constant identifying the Format Type the AudioStreaming interface is using. 4 bSubslotSize 1 Number The number of bytes occupied by one audio subslot. Can be 1, 2, 3 or 4. 1 - 6 - 11 - 16 - 21 - 26 - 31 ここを編集
https://w.atwiki.jp/usb_audio/pages/15.html
原文：Audio Data Formats 1.0(PDF) USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 i Universal Serial Bus Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 ii Scope of This Release This document is the 1.0 release of this device class definition. Contributors Gal Ashour IBM Corporation Billy Brackenridge Microsoft Corporation Oren Tirosh Altec Lansing Craig Todd Dolby Laboratories Remy Zimmermann Logitech Geert Knapen Philips ITCL Interleuvenlaan 74-76 B-3001 Leuven-Heverlee BELGIUM Phone +32 16 390 734 Fax +32 16 390 600 E-mail Geert.Knapen(at)innet.be Revision History Revision Date Filename Author Description 0.1 Dec. 1, 96 Frmts01.doc Geert Knapen Initial version 0.2 Jan. 1, 97 Frmts02.doc Geert Knapen Corrected typos. 0.3 Mar. 1, 97 Frmts03.doc Geert Knapen Adapted template and contents to correspond with core document. 0.9rc Apr. 1, 97 Frmts09rc.doc Geert Knapen Brought in line with core document. Added Type II descriptors and requests. 0.9 May 1, 97 Frmts09.doc Geert Knapen Added details for MPEG and AC-3. Added format-specific requests. 0.9CE Sep 1, 97 Frmts09CE.doc Geert Knapen Copy-edited for publication on the web. 0.9a Oct 1, 97 Frmts09a.doc Geert Knapen Incorporated RRs 1.0RC Mar 1, 98 Frmts10RC.doc Geert Knapen Added the Transfer Delimiter concept. Cleaned up the formatting. 1.0 Mar 18, 98 Frmts10.doc Geert Knapen Changed all references to 1.0 USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 iii Copyright © 1997, USB Implementers ForumAll rights reserved. INTELLECTUAL PROPERTY DISCLAIMER THIS SPECIFICATION IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER INCLUDING ANY WARRANTY OF MERCHANTABILITY, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION, OR SAMPLE. A LICENSE IS HEREBY GRANTED TO REPRODUCE AND DISTRIBUTE THIS SPECIFICATION FOR INTERNAL USE ONLY. NO OTHER LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY OTHER INTELLECTUAL PROPERTY RIGHTS IS GRANTED OR INTENDED HEREBY. AUTHORS OF THIS SPECIFICATION DISCLAIM ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF PROPRIETARY RIGHTS, RELATING TO IMPLEMENTATION OF INFORMATION IN THIS SPECIFICATION. AUTHORS OF THIS SPECIFICATION ALSO DO NOT WARRANT OR REPRESENT THAT SUCH IMPLEMENTATION(S) WILL NOT INFRINGE SUCH RIGHTS. Dolby™, AC-3™, Pro Logic™ and Dolby Surround™ are trademarks of Dolby Laboratories, Inc. All other product names are trademarks, registered trademarks, or service marks of their respective owners. Please send comments via electronic mail to techsup(atusb.org) USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 iv Table of Contents Scope of This Release.........................................................................................................ii Contributors........................................................................................................................ii Revision History ..................................................................................................................ii Table of Contents ...............................................................................................................iv List of Tables .......................................................................................................................v 1 Introduction ..................................................................................................................6 1.1 Related Documents .................................................................................................6 1.2 Terms and Abbreviations.........................................................................................6 2 Audio Data Formats......................................................................................................8 2.1 Transfer Delimiter....................................................................................................8 2.2 Type I Formats ........................................................................................................8 2.2.1 USB Packets ....................................................................................................8 2.2.2 Audio Subframe................................................................................................9 2.2.3 Audio Frame.....................................................................................................9 2.2.4 Audio Streams ..................................................................................................9 2.2.5 Type I Format Type Descriptor .......................................................................10 2.2.6 Supported Formats .........................................................................................11 2.3 Type II Formats .....................................................................................................12 2.3.1 Encoded Audio Frames...................................................................................12 2.3.2 Audio Bitstreams.............................................................................................12 2.3.3 USB Packets ..................................................................................................13 2.3.4 Bandwidth Allocation.......................................................................................13 2.3.5 Timing ............................................................................................................13 2.3.6 Type II Format Type Descriptor ......................................................................13 2.3.7 Rate feedback ................................................................................................15 2.3.8 Supported Formats .........................................................................................15 2.4 Type III Formats ....................................................................................................26 2.4.1 Type III Format Type Descriptor .....................................................................26 3 Adding New Audio Data Formats ..............................................................................28 Appendix A. Additional Audio Device Class Codes .....................................................29 A.1 Audio Data Format Codes......................................................................................29 A.1.1 Audio Data Format Type I Codes....................................................................29 A.1.2 Audio Data Format Type II Codes...................................................................29 A.1.3 Audio Data Format Type III Codes..................................................................29 A.2 Format Type Codes ...............................................................................................30 A.1 Format-Specific Control Selectors .........................................................................30 A.3 ..................................................................................................................................30 A.3.1 MPEG Control Selectors.................................................................................30 A.3.2 AC-3 Control Selectors ...................................................................................30 USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 v List of Tables Table 2-1 Type I Format Type Descriptor........................................................................10 Table 2-2 Continuous Sampling Frequency ...................................................................10 Table 2-3 Discrete Number of Sampling Frequencies....................................................11 Table 2-4 Type II Format Type Descriptor.......................................................................13 Table 2-5 Continuous Sampling Frequency ...................................................................14 Table 2-6 Discrete Number of Sampling Frequencies....................................................14 Table 2-7 MPEG Format-Specific Descriptor ..................................................................16 Table 2-8 Set MPEG Control Request Values .................................................................18 Table 2-9 Get MPEG Control Request Values.................................................................18 Table 2-10 Dual Channel Control Parameter Block ........................................................19 Table 2-11 Second Stereo Control Parameter Block ......................................................19 Table 2-12 Multilingual Control Parameter Block...........................................................20 Table 2-13 Dynamic Range Control Parameter Block ....................................................20 Table 2-14 Scaling Control Parameter Block ..................................................................21 Table 2-15 High/Low Scaling Control Parameter Block .................................................21 Table 2-16 AC-3 Format-Specific Descriptor...................................................................22 Table 2-17 Set AC-3 Control Request Values..................................................................23 Table 2-18 Get AC-3 Control Request Values .................................................................23 Table 2-19 Mode Control Parameter Block .....................................................................24 Table 2-20 Dynamic Range Control Parameter Block ....................................................24 Table 2-21 Scaling Control Parameter Block ..................................................................25 Table 2-22 High/Low Scaling Control Parameter Block .................................................25 Table 2-23 Type III Format Type Descriptor....................................................................26 Table 2-24 Continuous Sampling Frequency .................................................................27 Table 2-25 Discrete Number of Sampling Frequencies..................................................27 Table A-1 Audio Data Format Type I Codes....................................................................29 Table A-2 Audio Data Format Type II Codes...................................................................29 Table A-3 Audio Data Format Type III Codes..................................................................29 Table A-4 Format Type Codes .........................................................................................30 Table A-5 MPEG Control Selectors .................................................................................30 Table A-6 AC-3 Control Selectors....................................................................................30 1 - 6 - 11 - 16 - 21 - 26 - 31 ここを編集
https://w.atwiki.jp/usb_audio/pages/21.html
原文：Audio Data Formats 1.0(PDF) USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 6 1 Introduction The intention of this document is to describe in detail all the Audio Data Formats that are supported by the Audio Device Class. This document is considered an integral part of the Audio Device Class Specification, although subsequent revisions of this document are independent of the revision evolution of the main USB Audio Specification. This is to easily accommodate the addition of new Audio Data Formats without impeding the core USB Audio Specification. 1.1 Related Documents · Universal Serial Bus Specification, 1.0 final draft revision (also referred to as the USB Specification). In particular, see Chapter 9, “USB Device Framework.” · Universal Serial Bus Device Class Definition for Audio Data Formats (referred to in this document as USB Audio Data Formats). · Universal Serial Bus Device Class Definition for Terminal Types (referred to in this document as USB Audio Terminal Types). · ANSI S1.11-1986 standard. · MPEG-1 standard ISO/IEC 111172-3 1993. · MPEG-2 standard ISO/IEC 13818-3 Feb. 20, 1997. · Digital Audio Compression Standard (AC-3), ATSC A/52 Dec. 20, 1995. (available from http //www.atsc.org) · ANSI/IEEE-754 floating-point standard. · ISO/IEC 958 International Standard Digital Audio Interface and Annexes. · ISO/IEC 1937 standard. · ITU G.711 standard. 1.2 Terms and Abbreviations This section defines terms used throughout this document. For additional terms that pertain to the Universal Serial Bus, see Chapter 2, “Terms and Abbreviations,” in the USB Specification. Audio Frame A collection of audio subframes, each containing a PCM audio sample of a different physical audio channel, taken at the same moment in time. Audio Stream A concatenation of a potentially very large number of audio frames ordered according to ascending time. Audio Subframe Holds a single PCM audio sample. DVD Acronym for Digital Versatile Disc. Encoded Audio Bitstream A concatenation of a potentially very large number of encoded audio frames, ordered according to ascending time. Encoded Audio Frame A sequence of bits that contains an encoded representation of one or more physical audio channels. MPEG Acronym for Moving Pictures Expert Group. PCM Acronym for Pulse Coded Modulation. Transfer Delimiter A unique token that indicates an interruption in an isochronous data packet stream. Can be either a zerolength data packet or the absence of an isochronous transfer in a certain USB frame. USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 7 blank page USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 8 2 Audio Data Formats Audio Data Formats can be divided in three main groups according to type. The first group, Type I, deals with audio data streams that are constructed on a sample-by-sample basis. Each audio sample is represented by a single independent symbol and the data stream is built up by concatenating those symbols. Different compression schemes may be used to transform the audio samples into symbols. If multiple physical audio channels are formatted into a single audio channel cluster, then samples at time x of subsequent channels are transmitted interleaved, according to the cluster channel ordering as described in the main USB Audio Specification, followed by samples at time x+1, interleaved in the same fashion and so on. The notion of physical channels is explicitly preserved during transmission. A typical example of Type I formats is the standard PCM audio data. The second group, Type II, deals with those formats that do not preserve the notion of physical channels during the transmission. Typically, all non-PCM encoded audio data streams belong to this group. A number of audio samples, often originating from multiple physical channels, are encoded into a number of bits in such a way that, after transmission, the original audio samples can be reconstructed to a certain degree of accuracy. The number of bits used for transmission is typically one or more orders of magnitude smaller than the number of bits needed to represent the original PCM audio samples, effectively realizing a considerable bandwidth reduction during transmission. The third group, Type III, contains special formats that do not fit in both previous groups. In fact, they mix characteristics of Type I and Type II groups to transmit audio data streams. One or more non-PCM encoded audio data streams are packed into “pseudo-stereo samples” and transmitted as if they were real stereo PCM audio samples. The sampling frequency of these pseudo samples matches the sampling frequency of the original PCM audio data streams. Therefore, clock recovery at the receiving end is easier than it is in the case of Type II formats. The drawback is that unless multiple non-PCM encoded streams are packed into one pseudo stereo stream, more bandwidth than necessary is consumed. Section A.1, “Audio Data Format Codes” summarizes the Audio Data Formats that are currently supported in the Audio Device Class. The following sections explain those formats in more detail. 2.1 Transfer Delimiter Isochronous data streams are continuous in nature, although the actual number of bytes sent per packet may vary throughout the lifetime of the stream (for rate adaptation purposes for instance). To indicate a temporary stop in the isochronous data stream without closing the pipe (and thus relinquishing the USB bandwidth), an in-band Transfer Delimiter needs to be defined. This specification considers two situations to be a Transfer Delimiter. The first is a zero-length data packet and the second is the absence of an isochronous transfer in a particular USB frame. Both situations are considered equivalent and the audio function is expected to behave the same. However, the second type consumes less isochronous USB bandwidth (i.e. zero bandwidth). In both cases, this specification considers a Transfer Delimiter to be an entity that can be sent over the USB. 2.2 Type I Formats The following sections describe the Audio Data Formats that belong to Type I. A number of terms and their definition are presented. 2.2.1 USB Packets Audio data streams that are inherently continuous must be packetized when sent over the USB. The quality of the packetizing algorithm directly influences the amount of effort needed to reconstruct a reliable sample clock at the receiving side. The goal must be to keep the instantaneous number of samples USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 9 per frame (ni) as close as possible to the average number of samples per frame, (nav). The average nav should be calculated as a sliding average over a period of 256 frames. If the sampling rate is a constant, the allowable variation on ni is limited to one sample, that is, Dni = 1. This implies that all packets must either contain INT (nav ) (small packet) or INT (nav ) + 1 (large packet) samples. For all i ni = INT (nav) | INT (nav) + 1 Note In the case where nav = INT (nav ), ni may vary between INT (nav) - 1 (small packet), INT (nav) (medium packet) and INT (nav) + 1 (large packet). To limit the needed buffer depths to acceptable limits, this specification limits the cumulative difference between nav and ni to ±1.5 samples. If the sampling rate can be varied (to implement pitch control), the allowable pitch shift is 1kHz/ms. That is, the allowable variation on ni is limited to one sample per frame. For all i ni+1 = ni ± 1 Pitch control is restricted to adaptive endpoints only. AudioStreaming interfaces that support pitch control on their isochronous endpoint are required to report this in the class-specific endpoint descriptor. In addition, a Set/Get Pitch Control request is required to enable or disable the pitch control functionality. 2.2.2 Audio Subframe The basic structure used to represent audio data is the audio subframe. An audio subframe holds a single audio sample. An audio subframe always contains an integer number of bytes. This specification limits the possible audio subframe sizes (bSubframeSize) to 1, 2, 3 or 4 bytes per audio subframe. An audio sample is represented using a number of bits (bBitResolution) less than or equal to the total number of bits available in the audio subframe, i.e. bBitResolution £ bSubframeSize*8. AudioStreaming endpoints must be constructed in such a way that a valid transfer can take place as long as the reported audio subframe size (bSubframeSize) is respected during transmission. If the reported bits per sample (bBitResolution) do not correspond with the number of significant bits actually used during transfer, the device will either discard trailing significant bits ([actual_bits_per_sample] bBitResolution) or interpret trailing zeros as significant bits ([actual_bits_per_sample] bBitResolution). 2.2.3 Audio Frame An audio frame consists of a collection of audio subframes, each containing an audio sample of a different physical audio channel, taken at the same moment in time. The number of audio subframes in an audio frame equals the number of logical audio channels in the audio channel cluster. The ordering of the audio subframes in the audio frame obeys the rules set forth in the USB Audio Specification. All audio subframes must have the same audio subframe size. 2.2.4 Audio Streams An audio stream is a concatenation of a potentially very large number of audio frames, ordered according to ascending time. Streams are packetized when transported over USB whereby USB packets can only contain an integer number of audio frames. Each packet always starts with the same channel, and the channel order is respected throughout the entire transmission. If, for any reason, there are no audio frames available to construct a USB packet, a Transfer Delimiter must be sent instead. USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 10 2.2.5 Type I Format Type Descriptor The Type I format type descriptor starts with the usual three fields bLength, bDescriptorType, and bDescriptorSubtype. The bFormatType field indicates this is a Type I descriptor. The bNrChannels field contains the number of physical channels in the audio data stream. The bSubframeSize field indicates how many bytes are used to transport an audio subframe. The bBitResolution field indicates how many bits of the total number of available bits in the audio subframe are truly used by the audio function to convey audio information. The sampling frequency capabilities of the isochronous data endpoint of the AudioStreaming Interface are reported as well. Depending on the bSamFreqType field, the length of the descriptor varies and the interpretation of the trailing fields differs. Sampling frequencies occupy three bytes and are expressed in Hz to support over-sampled, reduced bit-resolution systems (the range is from 0 to 16,777,215 Hz). Table 2-1 Type I Format Type Descriptor Offset Field Size Value Descriptio 0 bLength 1 Number Size of this descriptor, in bytes 8+(ns*3) 1 bDescriptorType 1 Constant CS_INTERFACE descriptor type. 2 bDescriptorSubtype 1 Constant FORMAT_TYPE descriptor subtype. 3 bFormatType 1 Constant FORMAT_TYPE_I. Constant identifying the Format Type the AudioStreaming interface is using. 4 bNrChannels 1 Number Indicates the number of physical channels in the audio data stream. 5 bSubframeSize 1 Number The number of bytes occupied by one audio subframe. Can be 1, 2, 3 or 4. 6 bBitResolution 1 Number The number of effectively used bits from the available bits in an audio subframe. 7 bSamFreqType 1 Number Indicates how the sampling frequency can be programmed 0 Continuous sampling frequency1..255 The number of discrete sampling frequencies supported by the isochronous data endpoint of the AudioStreaming interface (ns) 8... See sampling frequency tables, below. Depending on the value in the bSamFreqType field, the layout of the next part of the descriptor is as shown in the following tables. Table 2-2 Continuous Sampling Frequency Offset Field Size Value Descriptio 1 - 6 - 11 - 16 - 21 - 26 - 31 ここを編集
https://w.atwiki.jp/usb_audio/pages/63.html
原文：Audio Devices Rev. 2.0 Spec and Adopters Agreement(ZIP) Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 16 Offset Field Size Value Description 5 bBitResolution 1 Number The number of effectively used bits from the available bits in an audio subslot. 2.3.1.7 Type I Supported Formats The following paragraphs list all currently supported Type I Audio Data Formats. The bit allocations in the bmFormats field of the class-specific AS interface descriptor for the different Type I Audio Data Formats can be found in Appendix A.2.1, “Audio Data Format Type I Bit Allocations.” 2.3.1.7.1 PCM Format The PCM (Pulse Coded Modulation) format is the most commonly used audio format to represent audio data streams. The audio data is not compressed and uses a signed two’s-complement fixed point format. It is left-justified (the sign bit is the Msb) and data is padded with trailing zeros to fill the remaining unused bits of the subslot. The binary point is located to the right of the sign bit so that all values lie within the range [-1, +1). 2.3.1.7.2 PCM8 Format The PCM8 format is introduced to be compatible with the legacy 8-bit wave format. Audio data is uncompressed and uses 8 bits per sample (bBitResolution = 8). In this case, data is unsigned fixed-point, left-justified in the audio subslot, Msb first. The range is [0,255]. 2.3.1.7.3 IEEE_FLOAT Format The IEEE_FLOAT format is based on the ANSI/IEEE-754 floating-point standard. Audio data is represented using the basic single-precision format. The basic single-precision number is 32 bits wide and has an 8-bit exponent and a 24-bit mantissa. Both mantissa and exponent are signed numbers, but neither is represented in two s-complement format. The mantissa is stored in sign magnitude format and the exponent in biased form (also called excess-n form). In biased form, there is a positive integer (called the bias) which is subtracted from the stored number to get the actual number. For example, in an eight-bit exponent, the bias is 127. To represent 0, the number 127 is stored. To represent -100, 27 is stored. An exponent of all zeroes and an exponent of all ones are both reserved for special cases, so in an eight-bit field, exponents of -126 to +127 are possible. In the basic floating-point format, the mantissa is assumed to be normalized so that the most significant bit is always one, and therefore is not stored. Only the fractional part is stored. Denormalized (exponent = 0) values are considered to be zero. The 32-bit IEEE-754 floating-point word is broken into three fields. The most significant bit stores the sign of the mantissa, the next group of 8 bits stores the exponent in biased form, and the remaining 23 bits store the magnitude of the fractional portion of the mantissa. For further information, refer to the ANSI/IEEE-754 standard. The data is conveyed over USB using 32 bits per sample (bBitResolution = 32; bSubslotSize = 4). 2.3.1.7.4 ALaw Format and μLaw Format Starting from 12- or 16-bits linear PCM samples, simple compression down to 8-bits per sample (one byte per sample) can be achieved by using logarithmic companding. The compressed audio data uses 8 bits per sample (bBitsPerSample = 8). Data is signed fixed point, left-justified in the subslot, Msb first. The compressed range is [-128,128]. The difference between Alaw and μLaw compression lies in the formulae used to achieve the compression. Refer to the ITU G.711 standard for further details. Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 17 2.3.1.7.5 Type I Raw Data This audio format is included to allow transport of data (audio or other) over a USB AudioStreaming interface in the form of PCM-like audio slots when the actual format or even the meaning of the transported data is unknown. The USB pipe simply acts as a pass-through. As a consequence, such data can never be interpreted inside the audio function and can only be routed from an Input Terminal to one or more Output Terminals. From a USB standpoint, the data is packed as if it were Type I formatted audio data, but the data is never to be interpreted as being audio data. 2.3.2 Type II Formats Type II formats are used to transmit non-PCM encoded audio data into bit streams that consist of a sequence of encoded audio frames. 2.3.2.1 Encoded Audio Frames An encoded audio frame is a sequence of bits that contains an encoded representation of one or more physical audio channels. The encoding takes place over a fixed number of audio slots. Each encoded audio frame contains enough information to entirely reconstruct the audio samples (albeit not lossless), encoded in the encoded audio frame. No information from adjacent encoded audio frames is needed during decoding. The number of audio slots used to construct one encoded audio frame depends on the encoding scheme. (For MPEG, the number of slots per encoded audio frame (nf) is 384 for Layer I or 1152 for Layer II. For AC-3, the number of slots is 1536.) In most cases, the encoded audio frame represents multiple physical audio channels. The number of bits per encoded audio frame may be variable. The content of the encoded audio frame is defined according to the implemented encoding scheme. Where applicable, the bit ordering shall be MSB first, relative to existing standards of serial transmission or storage of that encoding scheme. An encoded audio frame represents an interval longer than the USB (micro)frame. This is typical of audio compression algorithms that use psycho-acoustic or vocal tract parametric models. cite(Note} It is important to make a clear distinction between a USB frame and an encoded audio frame. The overloaded use of the term frame could cause confusion. Therefore, this specification will always use the qualifier ‘encoded audio’ to refer to MPEG or AC-3 encoded audio frames. 2.3.2.2 Audio Bit Streams An encoded audio bit stream is a concatenation of a potentially very large number of encoded audio frames, ordered according to ascending time. Subsequent encoded audio frames are independent and can be decoded separately. 2.3.2.3 USB Packets Encoded audio bit streams are packetized when transported over an isochronous pipe. Each virtual frame packet potentially contains only part of a single encoded audio frame. Packet sizes are determined according to the short-packet protocol. The encoded audio frame is broken down into a number of packets, each containing wMaxPacketSize bytes except for the last packet, which may be smaller and contains the remainder of the encoded audio frame. If the MaxPacketsOnly bit D7 in the bmAttributes field of the class-specific endpoint descriptor is set, the last (short) packet must be padded with zero bytes to wMaxPacketSize length. No virtual frame packet may contain bits belonging to different encoded audio frames. If the encoded audio frame length is not a multiple of 8 bits, the last byte in the last packet is padded with zero bits. The decoder must ignore all padded extra bits and bytes. Consecutive encoded audio frames are separated by at least one Transfer Delimiter. A Transfer Delimiter must be sent in all virtual frames until the next encoded audio frame is due. The above rules guarantee that a new encoded audio frame always starts on a virtual frame packet boundary. Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 18 2.3.2.4 Bandwidth Allocation The encoded audio frame time tf equals the number of audio slots per encoded audio frame nf divided by the sampling rate fs of the original audio samples. ここに画像 The allocated bandwidth for the pipe must accommodate for the largest possible encoded audio frame to be transmitted within an encoded audio frame time. This should take into account the Transfer Delimiter requirement and any differences between the time base of the stream and the USB (micro)frame timer. The device may choose to consume more bandwidth than necessary (by increasing the reported wMaxPacketSize) to minimize the time needed to transmit an entire encoded audio frame. This can be used to enable early decoding and therefore minimize system latency. 2.3.2.5 Timing The timing reference point is the beginning of an encoded audio frame. Therefore, the USB packet that contains the first bits (usually the encoded audio frame sync word) of the encoded audio frame is used as a timing reference in USB space. This USB packet is called the reference packet. The transmission of the reference packet of an encoded audio frame should begin at the target playback time of that frame (minus the endpoint’s reported delay) rounded to the nearest USB (micro)frame time. This guarantees that, at the receiving end, the arrival of subsequent reference packets matches the encoded audio frame time tf as closely as possible. 2.3.2.6 Type II Format Type Descriptor The Type II Format Type descriptor starts with the usual three fields bLength, bDescriptorType and bDescriptorSubtype. The bFormatType field indicates this is a Type II descriptor. The wMaxBitRate field contains the maximum number of bits per second this interface can handle. It is a measure for the buffer size available in the interface. The wSlotsPerFrame field contains the number of PCM audio slots contained within a single encoded audio frame. Table 2-3 Type II Format Type Descriptor Offset Field Size Value Description 0 bLength 1 Number Size of this descriptor, in bytes 8 1 bDescriptorType 1 Constant CS_INTERFACE descriptor type. 2 bDescriptorSubtype 1 Constant FORMAT_TYPE descriptor subtype. 3 bFormatType 1 Constant FORMAT_TYPE_II. Constant identifying the Format Type the AudioStreaming interface is using. 4 wMaxBitRate 2 Number Indicates the maximum number of bits per second this interface can handle. Expressed in kbits/s. 6 wSlotsPerFrame 2 Number Indicates the number of PCM audio slots contained in one encoded audio frame. Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 19 2.3.2.7 Rate feedback If the isochronous data endpoint needs explicit rate feedback (adaptive source, asynchronous sink), the feedback pipe must report the number of equivalent PCM audio slots. The host will accumulate this data and start transmission of an encoded audio frame whenever the current number of audio slots exceeds the number of slots per encoded audio frame. The remainder is kept in the accumulator. 2.3.2.8 Type II Supported Formats The following sections list all currently supported Type II Audio Data Formats. The bit allocations in the bmFormats field of the class-specific AS interface descriptor for the different Type II Audio Data Formats can be found in Appendix A.2.2, “Audio Data Format Type II Bit Allocations.” 2.3.2.8.1 MPEG Format Refer to the ISO/IEC 11172-3 1993 “Information technology -- Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s -- Part 3 Audio” and the ISO/IEC 13818-3 1998 “Information technology -- Generic coding of moving pictures and associated audio information -- Part 3 Audio” specifications for detailed format information. 2.3.2.8.2 AC-3 Format Refer to the Digital Audio Compression Standard (AC-3), ATSC A/52A Aug. 20, 2001 for detailed format information. 2.3.2.8.3 WMA Format This is an audio compression format from Microsoft. For technical and licensing information, contact Microsoft directly (http //www.microsoft.com/windows/windowsmedia/default.aspx). 2.3.2.8.4 DTS Format Refer to the ETSI Specification TS 102 114, “DTS Coherent Acoustics; Core and Extensions”. Available from http //webapp.etsi.org/action%5CPU/20020827/ts_102114v010101p.pdf. 2.3.2.8.5 Type II Raw Data This audio format is included to allow transport of data (audio or other) over a USB AudioStreaming interface in the form of a bit stream when the actual format or even the meaning of the transported data is unknown. The USB pipe simply acts as a pass-through. As a consequence, such data can never be interpreted inside the audio function and can only be routed from an Input Terminal to one or more Output Terminals. From a USB standpoint, the data is packed as if it were Type II formatted audio data, but the data is never to be interpreted as being audio data. 2.3.3 Type III Formats These formats are based upon the IEC61937 standard. The IEC61937 standard describes a method to transfer non-PCM encoded audio bit streams over an IEC60958 digital audio interface, together with the transfer of the accompanying “Channel Status” and “User Data.” The IEC60958 standard specifies a widely used method of interconnecting digital audio equipment with two-channel linear PCM audio. The IEC61937 standard describes a way in which the IEC60958 interface must be used to convey non-PCM encoded audio bit streams for consumer applications. The same basic techniques used in IEC61937 are reused here to convey non-PCM encoded audio bit streams over a Type III formatted audio stream. From a USB transfer standpoint, the data streaming over the interface looks exactly like two-channel 16 bit PCM audio data. Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 20 2.3.3.1 Type III Format Type Descriptor The bFormatType field indicates this is a Type III descriptor. The bSubSlotSize field indicates how many bytes are used to transport an audio subslot. The bBitResolution field indicates how many bits of the total number of available bits in the audio subslot are truly used by the audio function to convey audio information. Table 2-4 Type III Format Type Descriptor Offset Field Size Value Description 0 bLength 1 Number Size of this descriptor, in bytes 6 1 bDescriptorType 1 Constant CS_INTERFACE descriptor type. 2 bDescriptorSubtype 1 Constant FORMAT_TYPE descriptor subtype. 3 bFormatType 1 Constant FORMAT_TYPE_III. Constant identifying the Format Type the AudioStreaming interface is using. 4 bSubslotSize 1 Number The number of bytes occupied by one audio subslot. Must be set to two. 5 bBitResolution 1 Number The number of effectively used bits from the available bits in an audio subframe. 2.3.3.2 Type III Supported Formats Refer to the ISO/IEC 60958 and ISO/IEC 61937 (several parts) specifications for detailed format information. The bit allocations in the bmFormats field of the class-specific AS interface descriptor for the different Type III Audio Data Formats can be found in Appendix A.2.3, “Audio Data Format Type III Bit Allocations.” The following is a list of formats that is covered or will be covered by the above specifications. • IEC61937_AC-3 • IEC61937_MPEG-1_Layer1 • IEC61937_MPEG-1_Layer2/3 or IEC61937_MPEG-2_NOEXT • IEC61937_MPEG-2_EXT • IEC61937_MPEG-2_AAC_ADTS • IEC61937_MPEG-2_Layer1_LS • IEC61937_MPEG-2_Layer2/3_LS • IEC61937_DTS-I • IEC61937_DTS-II • IEC61937_DTS-III • IEC61937_ATRAC • IEC61937_ATRAC2/3 In addition, the WMA audio compression format as defined by Microsoft is supported. 2.3.4 Type IV Formats Type IV formats can only be used on external connections to the audio function that do not use a USB pipe for their data transport but that do need an AudioStreaming interface to control an encoder or decoder process in one or more of its Alternate Settings. A typical example of such a connection is an S/PDIF connector that is capable of handling both PCM stereo audio data streams (IEC60958) in one Alternate Release 2.0 May 31, 2006 20 1 - 6 - 11 - 16 - 21 - 26 - 31 ここを編集
https://w.atwiki.jp/usb_audio/pages/27.html
原文：Audio Terminal Types 1.0(PDF) USB Device Class Definition for Terminal Types Release 1.0 March 18, 1998 6 1 Introduction The intention of this document is to describe in detail all the Terminal Types that are supported by the Audio Device Class. This document is considered an integral part of the Audio Device Class Specification, although subsequent revisions of this document are independent of the revision evolution of the main Audio Device Class Specification. This is to easily accommodate the addition of new Terminal Types without impeding the core Audio Device Class Specification. 1.1 Scope The Audio Device Class Definition applies to all devices or functions embedded in composite devices. All audio signals inside an audio function start at an Input Terminal, pass through some Units, and leave the function through an Output Terminal. Units can manipulate the signal in various ways. Terminals represent the connections of the function to the outside world. As part of the Terminal descriptor, the wTerminalType field specifies the vendor’s suggested use of the Terminal. For example, a pair of speakers is a more suitable target for music output than a telephone line. This feature allows a vendor to ensure that applications use the device in a consistent and meaningful way. 1.2 Related Documents · Universal Serial Bus Specification, 1.0 final draft revision (also referred to as the USB Specification). In particular, see Chapter 9, “USB Device Framework”. · Universal Serial Bus Device Class Definition for Audio Data Formats (referred to in this document as USB Audio Data Formats). · Universal Serial Bus Device Class Definition for Terminal Types (referred to in this document as USB Audio Terminal Types). · ANSI S1.11-1986 standard. · MPEG-1 standard ISO/IEC 111172-3 1993. · MPEG-2 standard ISO/IEC 13818-3 Feb. 20, 1997. · Digital Audio Compression Standard (AC-3), ATSC A/52 Dec. 20, 1995. (available from http //www.atsc.org) · ANSI/IEEE-754 floating-point standard. · ISO/IEC 958 International Standard Digital Audio Interface and Annexes. · ISO/IEC 1937 standard. · ITU G.711 standard. 1.3 Terms and Abbreviations None. USB Device Class Definition for Terminal Types Release 1.0 March 18, 1998 7 2 Terminal Types The following is a list of possible Terminal Types. This list is non-exhaustive and will only be expandedin the future. 2.1 USB Terminal Types These Terminal Types describe Terminals that handle signals carried over the USB, usually throughisochronous pipes. These Terminal Types are valid for both Input and Output Terminals. Table 2-1 USB Terminal Types Terminal Type Code I/O Description USB Undefined 0x0100 I/O USB Terminal, undefined Type. USB streaming 0x0101 I/O A Terminal dealing with a signal carried over an endpoint in an AudioStreaming interface. The AudioStreaming interface descriptor points to the associated Terminal through the bTerminalLink field. USB vendor specific 0x01FF I/O A Terminal dealing with a signal carried over a vendor-specific interface. The vendor-specific interface descriptor must contain a field that references the Terminal. 2.2 Input Terminal Types These Terminal Types describe Terminals that are designed to record sounds. They either are physically part of the audio function or can be assumed to be connected to it in normal operation. These Terminal Types are valid only for Input Terminals Table 2-2 Input Terminal Types Termina Type Code I/O Description Input Undefined 0x0200 I Input Terminal, undefined Type. Microphone 0x0201 I A generic microphone that does not fit under any of the other classifications. Desktop microphone 0x0202 I A microphone normally placed on the desktop or integrated into the monitor. Personal microphone 0x0203 I A head-mounted or clip-on microphone. Omni-directional microphone 0x0204 I A microphone designed to pick up voice from more than one speaker at relatively long ranges. Microphone array 0x0205 I An array of microphones designed for directional processing using host-based signal processing algorithms. USB Device Class Definition for Terminal Types Release 1.0 March 18, 1998 8 Terminal Type Code I/O Description Processing microphone array 0x0206 I An array of microphones with an embedded signal processor. 2.3 Output Terminal Types These Terminal Types describe Terminals that produce audible signals that are intended to be heard by the user of the audio function. They either are physically part of the audio function or can be assumed to be connected to it in normal operation. These Terminal Types are only valid for Output Terminals. The distinction between headphones, desktop speakers, and room speakers may be used by applications to select different 3D signal processing algorithms. Table 2-3 Output Terminal Types Terminal Type Code I/O Description Output Undefined 0x0300 O Output Terminal, undefined Type. Speaker 0x0301 O A generic speaker or set of speakers that does not fit under any of the other classifications. Headphones 0x0302 O A head-mounted audio output device. Head Mounted Display Audio 0x0303 O The audio part of a VR head mounted display. The Associated Interfaces descriptor can be used to reference the HID interface used to report the position and orientation of the HMD. Desktop speaker 0x0304 O Relatively small speaker or set of speakers normally placed on the desktop or integrated into the monitor. These speakers are close to the user and have limited stereo separation. Room speaker 0x0305 O Larger speaker or set of speakers that are heard well anywhere in the room. Communication speaker 0x0306 O Speaker or set of speakers designed for voice communication. Low frequency effects speaker 0x0307 O Speaker designed for low frequencies (subwoofer). Not capable of reproducing speech or music. 2.4 Bi-directional Terminal Types These Terminal Types describe an Input and an Output Terminal for voice communication that are closely related. They should be used together for bi-directional voice communication. They may be used separately for input only or output only. These types require two Terminal descriptors. Both have the same type. The two Terminals are linked together through the bAssocTerminal fields in their respective Terminal descriptors. The Associated Interfaces descriptor can be used to reference a HID interface for conferencing functions. USB Device Class Definition for Terminal Types Release 1.0 March 18, 1998 9 Table 2-4 Bi-directional Terminal Types Terminal Type Code I/O Description Bi-directional Undefined 0x0400 I/O Bi-directional Terminal, undefined Type. Handset 0x0401 I/O Hand-held bi-directional audio device. Headset 0x0402 I/O Head-mounted bi-directional audio device. Speakerphone, no echo reduction 0x0403 I/O A hands-free audio device designed for host-based echo cancellation. Echo-suppressing speakerphone 0x0404 I/O A hands-free audio device with echo suppression capable of half-duplexoperation. Echo-canceling speakerphone 0x0405 I/O A hands-free audio device with echo cancellation capable of full-duplex operation. 2.5 Telephony Terminal Types These Terminal Types describe Terminals that connect to the PSTN or PBX. Initiating calls and monitoring call progress will be done through an associated interface which may be Communication, HID or Vendor-Specific class. These Terminals are bi-directional and follow the rules for bi-directional Terminals. Table 2-5 Telephony Terminal Types Terminal Type Code I/O Description Telephony Undefined 0x0500 I/O Telephony Terminal, undefined Type. Phone line 0x0501 I/O May be an analog telephone line jack, an ISDN line, a proprietary PBX interface, or a wireless link. Telephone 0x0502 I/O Device can be used as a telephone. When not in use as a telephone, handset is used as a bi-directional audio device. Down Line Phone 0x0503 I/O A standard telephone set connected to the device. When not in use as a telephone, it can be used as a bidirectional audio device. 2.6 External Terminal Types These Terminal Types describe external resources and connections that do not fit under the categories of Input or Output Terminals because they do not necessarily translate acoustic signals to or from the user of the computer. Most of them may be either Input or Output Terminals. USB Device Class Definition for Terminal Types Release 1.0 March 18, 1998 10 Table 2-6 External Terminal Types Terminal Type Code I/O Description External Undefined 0x0600 I/O External Terminal, undefined Type. Analog connector 0x0601 I/O A generic analog connector. Digital audio interface 0x0602 I/O A generic digital audio interface. Line connector 0x0603 I/O An analog connector at standard line levels. Usually uses 3.5mm. Legacy audio connector 0x0604 I/O An input connector assumed to be connected to the lineout of the legacy audio system of the host computer. Used for backward compatibility. S/PDIF interface 0x0605 I/O An S/PDIF digital audio interface. The Associated Interface descriptor can be used to reference an interface used for controlling special functions of this interface. 1394 DA stream 0x0606 I/O An interface to audio streams on a 1394 bus. 1394 DV stream soundtrack 0x0607 I/O An interface to soundtrack of A/V stream on a 1394 bus. 2.7 Embedded Function Terminal Types These Terminal Types represent connections to internal audio sources or sinks in a device. All have associated interfaces for control. These interfaces may be HID or other classes (vendor-specific, mass storage for CD-ROM, etc.). Devices capable of both playback and recording should follow the rules for bidirectional Terminals. Table 2-7 Embedded Terminal Types Terminal Type Code I/O Description Embedded Undefined 0x0700 I/O Embedded Terminal, undefined Type. Level Calibration Noise Source 0x0701 O Internal Noise source for level calibration (MPEG decoding, Dolby PrologicÔ, AC-3 etc.) Equalization Noise 0x0702 O Internal Noise source for measurements. CD player 0x0703 I Audio compact disc player or CD-ROM capable of audio playback. DAT 0x0704 I/O Digital Audio Tape. DCC 0x0705 I/O Digital Compact Cassette. 1 - 6 - 11 ここを編集
https://w.atwiki.jp/usb_audio/pages/58.html
原文：Audio Devices Rev. 2.0 Spec and Adopters Agreement(ZIP) USB Device Class Definition for Audio Devices Release 2.0 May 31, 2006 16 2 Management Overview The USB is very well suited for transport of audio ranging from low fidelity voice connections to high quality, multi-channel audio streams. The USB has become a ubiquitous connector on modern PC’s and is well-understood by most consumers today. As such, it has become the connector of choice for many peripherals and is indeed the simplest and most pervasive digital audio connector available today. With the advent of the High Speed USB, consumers can count on this medium to meet all of their audio needs today and into the future. Many applications from communications, to entertainment, to music recording and playback, can take advantage of audio features of the USB. In principle, a versatile bus specification like the USB provides many ways to propagate and/or control digital audio. For the industry, however, it is very important that audio transport mechanisms be well defined and standardized on the USB. Only in this way can interoperability be guaranteed among the many possible audio devices on the USB. Standardized audio transport mechanisms also help to keep software drivers as generic as possible. The Audio Device Class described in this document satisfies those requirements. It is written and revised by experts in the audio field. Other device classes that address audio in some way should refer to this document for their audio interface specification. An essential issue in audio is synchronization of the data streams. Indeed, the smallest artifacts are easily detected by the human ear. Therefore, a robust synchronization scheme on isochronous transfers has been developed and incorporated in the USB Specification. The Audio Device Class definition adheres to this synchronization scheme to transport audio data reliably over the bus. This document contains all necessary information for a designer to build a USB-compliant device that incorporates audio functionality. It specifies the standard and class-specific descriptors that must be present in each USB audio function. It further explains the use of class-specific requests that allow for full audio function control. A number of predefined data formats are listed and fully documented. Each format defines a standard way of transporting audio over the USB. Provisions have been made so that vendor-specific audio formats and compression schemes can be handled. Many of the changes introduced in Version 2.0 of the USB Specification for Audio Devices take advantage of the new features provided in the USB 2.0 Specification. With the additional bandwidth made available, high speed USB operation allows the transport of multiple channels of high bit rate audio. This expands the range of solutions provided by USB audio devices but also challenges the way in which they operate. In addition to supporting the additional bandwidth, the specification supports new codec types for consumer audio applications, provides numerous clarifications of the original specification and extensions to support various changes in the core specification. The changes are not generally backwards compatible to 1.0 because that would too severely limit this new class of devices. 2.1 Overview of Key Differences between ADC v1.0 and v2.0 The following list is not an exhaustive list of all changes that have been introduced. For complete information, refer to the full specification. Pay special attention to Sections 1 through 6! • Complete support for high speed operation - no longer are audio class devices limited to full speed operation. • The notion of physical and logical Audio channel clusters. • The number of predefined spatial locations has increased. In addition, a virtual spatial location called Raw Data was introduced. • Use of the interface association descriptor - The standard Interface Association mechanism is used to describe an Audio Interface Collection. The former class specific mechanism was deprecated. • Descriptor updates fixed offsets associated with many descriptors and enlarged three byte fields into four bytes. • Extensive support for interrupts to inform the host about dynamic changes that occur on the different addressable Entities (Clock Entities, Terminals, Units, interfaces and endpoints) inside the audio function. • More clarification text on the audio function. USB Device Class Definition for Audio Devices Release 2.0 May 31, 2006 17 • Audio Control Changes. – Control attribute changes. – Mixer Unit control request (set/get pairs changed). – Many updates in the control descriptions. • Added support for clock domains, clock description and clock control. • Added additional Audio Controls inside a Feature Unit (Input, Gain, Input Gain Pad …) • Added bit pairs in descriptors to indicate presence and programmability of every Control • Prohibited the use of Alternate Setting switching to change sampling frequencies. Instead, Clock Entities are introduced that can be manipulated (through the AudioControl interface) to select operating sampling frequencies. • Split off the examples in a separate document. • Allowed binding between physical buttons on the audio function and the corresponding Audio Control. Prescribed how this is done. • Added an Effect Unit to group algorithms that work on logical channels separately but require multiple parameters to manipulate the effect (as opposed to basic (single parameter) manipulation, performed in a Feature Unit). • Introduced Parametric Equalizer Section Effect Unit. • Rearranged Reverb, Modulation Delay and Dynamic Compressor PUs under the new Effect Unit. • Added the concept of audio function Category. The Category indicates the primary use of the audio function as envisioned by the manufacturer. • Added the Sampling Rate Converter Unit. • Added a means to express Latency of individual building blocks within the audio function. • Added Encoder support. USB Device Class Definition for Audio Devices 3 Functional Characteristics 3.1 Introduction In many cases, audio functionality does not exist as a standalone device. It is one capability that, together with other functions, constitutes a “composite” device. A perfect example of this is a DVD-ROM player, which can incorporate video, audio, data storage, and transport control. The audio function is thus located at the interface level in the device class hierarchy. It consists of a number of interfaces grouping related pipes that together implement the interface to the audio function. An audio function is considered to be a ‘closed box’ that has very distinct and well defined interfaces to the outside world. Audio functions are addressed through their audio interfaces. Each audio function must have a single AudioControl interface and can have zero or more AudioStreaming and zero or more MIDIStreaming interfaces. The AudioControl (AC) interface is used to access the Audio Controls of the function whereas the AudioStreaming (AS) interfaces are used to transport audio streams into and out of the function. The MIDIStreaming (MS) interfaces can be used to transport MIDI data streams into and out of the audio function. The collection of the single AudioControl interface and the AudioStreaming and MIDIStreaming interfaces that belong to the same audio function is called the Audio Interface Collection (AIC). A device can have multiple Audio Interface Collections active at the same time. These Collections are used to control multiple independent audio functions located in the same composite device. An Audio Interface Collection is described through the standard USB Interface Association mechanism that expresses interface binding via the Interface Association Descriptor (IAD). Note All MIDI-related information is grouped in a separate document, Universal Serial Bus Device Class Definition for MIDI Devices that is considered part of this specification. The remainder of this document will therefore not mention MIDIStreaming interfaces and their specifics anymore. The following figure illustrates the concept Audio FunctionAudio-StreamingInterfaceINUSBAudio-StreamingInterfaceINAudio-StreamingInterfaceINAudio-StreamingInterfaceOUTAudio-StreamingInterfaceOUTAudio-StreamingInterfaceOUTAudioControl InterfaceAudio InterfaceCollectionAlternate Settings Figure 3-1 Audio Function Global View 18 Release 2.0 May 31, 2006 USB Device Class Definition for Audio Devices Release 2.0 May 31, 2006 19 All functionality pertaining to controlling parameters that directly influence audio perception (like volume) are located inside the central rectangle and are exclusively controlled through the AudioControl interface. Streaming aspects of the communication to or from the audio function are handled through separate AudioStreaming interfaces. The AudioStreaming interface is primarily used for transporting audio data between the audio function and the outside world. However, all control data that is related specifically to the streaming behavior is also conveyed through the AudioStreaming interface. In particular, all control data that is used to influence the decoder or encoder process that potentially resides between the actual streaming endpoint and the audio function (e.g. conversion from AC-3 encoded stream to 5.1 physical audio channels) is conveyed through the AudioStreaming interface. Note that in some cases an AudioStreaming interface is only used to perform controlling functions while no actual data is transported over the interface. A physical S/PDIF connection to the audio function is a typical example. Although the actual audio data is coming in from the outside world (not through the USB), it might be necessary to control some aspects of the S/PDIF connection. In that case, the S/PDIF connection is represented by an AudioStreaming interface so that it becomes addressable through USB. Also note that the connection between the AudioStreaming interfaces and the audio function is not ‘solid’. The reason for this is that when seen from the inside of the audio function, each audio stream entering or leaving the audio function is represented by a special object, called a Terminal (see further). The Terminal concept abstracts the actual AudioStreaming interface inside the audio function and provides a logical view on the connection rather than a physical view. This abstraction allows audio channels within the audio function to be treated as ‘logical’ audio channels that do not have physical characteristics associated with them anymore (analog vs. digital, format, sampling rate, bit resolution, etc.). 3.2 Audio Interface Collection (AIC) On USB, an audio function is completely defined by its interfaces. An audio function has one AudioControl interface and zero d into an Audio Interface e The Audio Function class and Subclasses can be further qualified by the Function Protocol code. The ion sion of this specification so that enumeration stantiated. or more AudioStreaming interfaces, groupe Collection. The standard USB Interface Association mechanism is used to describe the Audio Interface Collection i.e. to bind those interfaces together. Interface Association is expressed via the standard USB Interface Association Descriptor (IAD). Every Interface Association Descriptor has a FunctionClass, FunctionSubClass and FunctionProtocol field that together identify the function that is represented by thAssociation. The following paragraphs define these fields for the Audio Device Class. 3.3 Audio Function Class An Interface Association has a Function Class code assigned to it. This specification requires that the Function Class code be the same as the Audio Interface Class code. The Audio Function class code is assigned by this specification. For details, see Appendix A.1, “Audio Function Class Code”. 3.4 Audio Function Subclass The Audio Function class is divided into Function Subclasses. At this moment, the Function SubClass codeis not used and must be set to FUNCTION_SUBCLASS_UNDEFINED. The assigned codes can be found in A.2, “Audio Function Subclass Codes” of this specification. All other Subclass codes are unused and reserved by this specification for future use. 3.5 Audio Function Protocol Funct Protocol code is used to reflect the current versoftware can decide which driver versions need to be in The assigned Protocol codes can be found in Appendix A.3, “Audio Function Protocol Codes” of this specification. All other Protocol codes are unused and reserved by this specification for future use. USB Device Class Definition for Audio Devices Release 2.0 May 31, 2006 20 h USB belong to this class. t, f this class, the only requirement is that it exposes one in aming interfaces for consuming or ss code is assigned by the USB. For details, see Appendix A.4, “Audio Interface Class Code”. re part of a certain Interface • AudioStreaming Interface Subclass ion. the current version of this specification. . ion Category indicates the primary intended use for the audio function. The following . ne A device set up to record audio from audible sources. • Headset A device with at least one speaker and at least one microphone designed to be worn or held ck and voice input capabilities. o another converting audio data from one encoding format to another (e.g. th at least one microphone and at least one speaker that is d optical inputs and outputs for connection to other devices. 3.6 Audio Interface Class The Audio Interface class groups all functions that can interact with USB-compliant audio data streams. All functions that convert between analog and digital audio domains can be part of this class. In addition, those functions that transform USB-compliant audio data streams into other USB-compliant audio data streams can be part of this class. Even analog audio functions that are controlled throug In facor an audio function to be part of AudioControl interface. No further interaction with the function is mandatory, although most functionsthe audio interface class will support one or more optional AudioStre producing one or more isochronous audio data streams. The Audio Interface cla 3.7 Audio Interface Subclass The Audio Interface class is divided into Subclasses. All audio functions a Subclass. The following three Interface Subclasses are currently defined in this specification • AudioControl Interface Subclass • MIDIStreaming Interface Subclass The assigned codes can be found in Appendix A.5, “Audio Interface Subclass Codes” of this specificatAll other Subclass codes are unused and reserved by this specification for future use. 3.8 Audio Interface Protocol The Audio Interface class and Subclasses can be further qualified by the Interface Protocol code. The Interface Protocol code is used to reflect The assigned codes can be found in Appendix A.6, “Audio Interface Protocol Codes” of this specificationAll other Protocol codes are unused and reserved by this specification for future use. 3.9 Audio Function Category The Audio Funct Function Categories are currently defined in this specification • Desktop Speaker One or more speakers set up in a small environment to provide audio intended primarily for one person. • Home Theater Several speakers set up in a moderately sized environment to provide audio levels significantly louder than a Desktop Speaker setup and intended to be clearly heard by multiple people• Micropho by a user to provide personal audio playba• Telephone A Headset or handset type device that also connects to a telephone system, (e.g. POTs, PBX, VoIP) capable of making and receiving telephone calls. • Converter A device that allows conversion of audio from one electrical or optical format t electrical or optical format, and/or AC-3 to PCM, etc.). • Voice/Sound recorder A device set up wi designed to operate, at least some of the time, independently of the Host to record and store audible sources and play back its recorded content. • IO Box A device designed to deliver one or more, possibly different, electrical an 1 - 6 - 11 - 16 - 21 - 26 - 31 - 36 - 41 - 46 - 51 - 56 - 61 - 66 - 71 - 76 - 81 - 86 - 91 - 96 - 101 - 106 - 111 - 116 - 121 - 126 - 131 - 136 - 141 ここを編集