約 5,013,881 件
https://w.atwiki.jp/digital111/
DigitaLは「Alliance of Valiant Arms」で２０１３年１０月２０日に設立されたクランです。 爆破ルールのクラン戦を中心に活動しており、マッチで高レートを目指し日々努力してます。 過去大会実績 AVAODL2014 Season1 爆破ビギナーリーグ BEブロック 優勝 参考動画 infix様との試合↓ ～クランメンバー紹介～ 名前 きょんしぃ 役職 クランマスター 兵種 PointMan 役割 エスパー乳毛 AIMが悪いため、裏取りしか狙いにいかないクソ野朗。 その裏取りもほぼ失敗するため完全なお荷物。 DigitaLのちんかす ニコ生コミュ→ http //com.nicovideo.jp/community/co1762070 名前 ReLight. 役職 オフィサー 兵種 RifleMan 役割 根暗 廃人なため階級のあがり方が他の追随を許さない。 また同じく廃人なため不規則な生活を好む。 DigitaLのパイプカット 名前 あぽろじゃいずぅ.* 役職 オフィサー 兵種 RifleMan or Sniper 役割 たこ (☝ ՞ਊ ՞)☝ﾀﾝﾃｰﾎﾞｩｼﾞｬﾝｷｰｗｗｗﾚｯﾂｗｗｗｹﾞｯｗｗ (乂՞ټ՞)✧ｽｸﾗｯﾁﾝｗｗｗｷｭｯｷｭｷｭｷｭｷｭｷｭｷｭｷｭｷｭ DigitaLの発狂する人 ニコ生コミュ→ http //com.nicovideo.jp/community/co2093573 名前 春野鈴蘭 役職 オフィサ－ 兵種 Sniper 役割 釈迦さん AIMがいいため頼りがいのあるSR。 安定したAIMで敵をなぎ倒す。振り向き70cm。 DigitaLのローセンシ ニコ生コミュ→ http //com.nicovideo.jp/community/co2165532 名前 春風葵乃 役職 オフィサー 兵種 RifleMan 役割 パパ 戦場の状況判断をいち早く掴み、味方に最適な指示を出す。 考え込まれた動きで敵をなぎ倒す。 DigitaLのパパ ニコ生コミュ→ http //com.nicovideo.jp/community/co2165530 名前 安心と信頼のかーく 役職 オフィサー 兵種 RifleMan 役割 低スペック 通称おっさん、皆でPC組んで送ってあげようプロジェクト推進中。 キチガイという言葉ががよく合う変態 。 DigitaLの何でそのPCでできるの 名前 吾輩はてちゅである 役職 オフィサー 兵種 PointMan 役割 てつはう爆弾 通称てつ、言葉通り戦場に投げ込むことによって その爆風は広範囲に拡散するといわれている。 DigitaLの旧式グレネード ニコ生コミュ→ http //com.nicovideo.jp/community/co1961169 名前 HamTerᴿᴼᵁ 役職 メンバー 兵種 Sniper 役割 とっとこ～ StarDustからDigitaLを救うために来た戦士。 通称ハムさん、SRとRM併用のマルチプレイヤー DigitaLの大好きなのはひまわりの種 名前 Re_Right 役職 メンバー 兵種 RifleMan 役割 らいとさん 似たり寄ったりな名前のタカシがいるため 敵の報告を混乱させることができる DigitaLの名前パクられ代表 引用：TSサーバの文章 PMのグレ色々紹介してるので興味があったら是非♪ ～クラメン募集～ 微ガチ、TS3、聞き線ｘ（一時的ならおｋ）、IN率高め 以上の条件を満たし、 勝ちたいという向上心を持つ方を募集します。
https://w.atwiki.jp/utauuuta/pages/2414.html
【登録タグ D 曲 雪歌ユフ 風原】 作詞：風原 作曲：風原 編曲：風原 唄：雪歌ユフ 曲紹介 あなたとわたしのインターフェイス。 ユフ誕2011参加楽曲 歌詞 （動画歌詞より転載） Digital Audio Wedding☆ 音と電気と時間で夢を見せて Dokidoki Tokidoki Mojimoji まだどこか処理オチする※１ふたりの新生活 これから始まる ふたりの暮らし EQ※２も大事だよね でもね だけど ほんとの気持ちは 私のS/N※３良くして 時にはサイドチェインコンプ※４くれなきゃやだ だけど行き過ぎたときは ちゃんとリミッター※５欲しいの Digital Audio Wedding☆ 音と電気と時間で魔法をかけて Dondon Tsugitsugi Madamada これくらいじゃ私はピーク※６しないんだから まだまだこれから ふたりの暮らし レイテンシ※７もあるよね でもね だけどね ほんとの気持ちは バッファサイズ最少※８ 時には クリップ※９もあるけど これもそれもすべて 好きの逆位相※10なの Digital Audio Wedding☆ 音と電気と時間で想い伝えて MIDI※11 どこまでも私を ゲインして※12 Digital Audio Wedding☆ 音と電気と時間で気持ち高めて MIDI※13 どこまでも私を マキシマイズ※14してよね ふたり仲良く ミックスダウン♪※15 【蛇足なフリガナ集】 ※１ ぎこちない ※２ ゆずりあい ※３ ごきげん ※４ ワガママ言わせて ※５ 叱って ※６ 満足 ※７ 溜め込むこと ※８ 素直に伝えたいの ※９ 怒らせちゃったり ※10 裏返し ※11 もっといつも大好きって言って！ ※12 喜ばせて ※13 もっといつも大好きって言わせて！ ※14 幸せに ※15 おやすみ コメント 名前 コメント
https://w.atwiki.jp/usb_audio/pages/25.html
原文：Audio Data Formats 1.0(PDF) USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 21 The Scaling Control can support all possible Control attributes (CUR, MIN, MAX, and RES). The valid range for the CUR, MIN, MAX, and RES attributes is from zero (0x00) to 255/256 (0xFF). The Scaling Control honors the request to the best of its abilities. It may round the bScale attribute value to its closest available setting. It will report this rounded setting when queried during a Get MPEG Control request. Table 2-14 Scaling Control Parameter Block Control Selector MP_SCALING_CONTROL wLength 1 Offset Field Size Value Description 0 bScale 1 Number The setting for the attribute of the Scaling Control. 2.3.8.1.2.3.6 High/Low Scaling Control The High/Low Scaling Control is used to manipulate the two scaling coefficients used by MPEG decoders that implement an independent boost and cut scaling value for Dynamic Range Control (D5..4 = ‘11’ in the bmMPEGFeatures field of the MPEG format-specific descriptor). If this Control is addressed on a non-‘11’ decoder, the control pipe must indicate a stall. The High/Low Scaling Control can support all possible Control attributes (CUR, MIN, MAX, and RES). The valid range for the CUR, MIN, MAX, and RES attributes is from zero (0x00) to 255/256 (0xFF). The High/Low Scaling Control honors the request to the best of its abilities. It may round the bLowScale and bHighScale attribute values to their closest available settings. It will report these rounded settings when queried during a Get MPEG Control request. The bLowScale value is used by the MPEG decoder to scale the Dynamic Range control words that apply a gain increase (for low sound levels). The bHighScale value is used by the MPEG decoder to scale the Dynamic Range control words that apply a gain reduction (for high level sounds). Table 2-15 High/Low Scaling Control Parameter Block Control Selector MP_HILO_SCALING_CONTROL wLength 2 Offset Field Size Value Description 0 bLowScale 1 Number The setting for the attribute of the low level Scaling Control. 1 bHighScale 1 Number The setting for the attribute of the high level Scaling Control. 2.3.8.2 AC-3 Format In the current specification, only AC-3 decoding aspects are considered. Real-time AC-3 encoding peripherals are not (yet) available and consequently are not covered by this specification. 2.3.8.2.1 AC-3 Format-Specific Descriptor The wFormatTag field is a duplicate of the wFormatTag field in the class-specific AudioStreaming interface descriptor. The same field is used here to identify the format-specific descriptor. USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 22 The bmBSID bitmap field describes which bit stream ID modes this decoder is capable of processing. BSID modes can range from 0 to 31. A bit set indicates that BSID mode [bit_position] is supported. Standard AC-3 decoders must be capable of processing at least BSID modes 0 to 8. Therefore, the lower 9 bits of the bmBSID field must be set. The bmAC3Features bitmap field indicates compression-related features. Bits D3..0 indicate which mode the decoder supports. To ease the design of decoder products, Dolby Digital ICs offer standard operating modes called “Line Mode” and “RF Mode.” These modes are included within the Dolby Digital decoder IC itself, thus greatly simplifying the implementation of dialog normalization, dynamic range control and downmixing functions, all of which are necessary in Dolby Digital products. Two “Custom Modes” offer additional design flexibility aimed at more esoteric audio products for which additional implementation cost and complexity are not of primary concern. Bits D5..4. indicate which type of Dynamic Range Control the AC-3 decoder supports. Some decoders do not implement DRC (D5..4 = ‘00’). If implemented, the DRC can either use the stream embedded gain parameters as is (D5..4 = ‘01’) or can provide for additional DRC scaling factors either a single scaling factor that influences both the boost and cut value simultaneously (D5..4 = ‘10’), or a separate scaling factor for the boost and the cut value (D5..4 = ‘11’) All other bits are reserved. Table 2-16 AC-3 Format-Specific Descriptor Offset Field Size Value Description 0 bLength 1 Number Size of this descriptor, in bytes 10 1 bDescriptorType 1 Constant CS_INTERFACE descriptor type. 2 bDescriptorSubtype 1 Constant FORMAT_SPECIFIC descriptor subtype. 3 wFormatTag 2 Constant AC-3. Constant identifying the precise format the AudioStreaming interface is using. 5 bmBSID 4 Bitmap A bit set to 1 indicates that the corresponding BSID mode is supported. 9 bmAC3Features 1 Bitmap A bit set to 1 indicates that the mentioned feature is supported D0 RF modeD1 Line modeD2 Custom0 modeD3 Custom1 modeD5..4 Internal Dynamic Range Control 00 = not supported.01 = supported but not scalable.10 = scalable, common boost and cut scaling value.11 = scalable, separate boost and cut scaling value.D7..6 Reserved USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 23 2.3.8.2.2 AC-3 Format-Specific Requests The following paragraphs describe the Set and Get AC-3 Control requests. 2.3.8.2.2.1 Set AC-3 Control Request This request is used to set an attribute of an AC-3 Control inside an AudioStreaming interface of the audio function. Table 2-17 Set AC-3 Control Request Values bmRequest Type bRequest wValue wIndex wLength Data 00100001B SET_CURSET_MINSET_MAXSET_RES CS Zero and Interface Length of Parameter block Parameter Block The bRequest field indicates which attribute the request is manipulating. The MIN, MAX, and RES attributes are usually not supported for the Set request. Further details on which attributes are supported for which Controls can be found in Section 2.3.8.2.2.3, “AC-3 Controls.” The wValue field specifies the Control Selector (CS) in the high byte and zero in the low byte. The Control Selector indicates which type of control this request is manipulating. If the request specifies an unknown or unsupported CS to that interface, the control pipe must indicate a stall. For a description of the parameter blocks for the different Controls that can be addressed through the Set AC-3 Control request, see Section 2.3.8.2.2.3, “AC-3 Controls.” 2.3.8.2.2.2 Get AC-3 Control Request This request returns the attribute setting of a specific AC-3 Control inside an AudioStreaming interface of the audio function. Table 2-18 Get AC-3 Control Request Values bmRequest Type bRequest wValue wIndex wLength Data 10100001B SET_CURSET_MINSET_MAXSET_RES CS Zero and Interface Length of Parameter block Parameter Block The bRequest field indicates which attribute the request is reading. The wValue field specifies the Control Selector (CS) in the high byte and zero in the low byte. The Control Selector indicates which type of control this request is addressing. If the request specifies an unknown or unsupported CS to that interface, the control pipe must indicate a stall. For a description of the parameter blocks for the different Controls that can be addressed through the Get AC-3 Control request, see Section 2.3.8.2.2.3, “AC-3 Controls.” 2.3.8.2.2.3 AC-3 Controls The following paragraphs present a detailed description of all possible AC-3 Controls an AudioStreaming interface can incorporate. For each Control, the layout of the parameter block together with the USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 24 appropriate Control Selector are listed. The Control Selector codes are defined in Section A.3.2, “AC-3 Control Selectors.” 2.3.8.2.2.3.1 Mode Control The Mode Control is used to change the compression mode of the AC-3 decoder in the AudioStreaming interface. A Mode Control can only support the CUR attribute. The valid range for the CUR attribute is described through the bmComprFeatures field of the AC-3 format-specific descriptor. Bits D3..0 describe which compression modes the AC-3 decoder supports. Valid values are · 0 RF mode · 1 Line mode · 2 Custom0 mode · 3 Custom1 mode If the Mode Control request specifies an unsupported mode, the control pipe must indicate a stall. The current setting can be queried during a Get AC-3 Control request. Table 2-19 Mode Control Parameter Block Control Selector AC_MODE_CONTROL wLength 1 Offset Field Size Value Description 0 bMode 1 Number The setting for the attribute of the Compression Mode Control 0 RF mode1 Line mode2 Custom0 mode3 Custom1 modeAll other values are reserved. 2.3.8.2.2.3.2 Dynamic Range Control The Dynamic Range Control (DRC) is used to enable or disable the Dynamic Range Control functionality of the decoder. The Dynamic Range Control can have only the current setting attribute (CUR). The position of the Dynamic Range Control switch can be either TRUE or FALSE. TRUE means that the AC- 3 decoder is using the Dynamic Range control words (possibly with additional scaling) contained in the AC-3 bit stream to control the audio dynamic range. FALSE means the control words are being ignored and the original signal dynamic range is being reproduced. The current setting of the Control can be queried using a Get AC-3 Control request. Table 2-20 Dynamic Range Control Parameter Block Control Selector MP_DYN_RANGE_CONTROL wLength 1 USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 25 Offset Field Size Value Description 0 bEnable 1 Bool The setting for the Dynamic Range Control CUR attribute. Enabled when TRUE, disabled when FALSE. 2.3.8.2.2.3.3 Scaling Control The Scaling Control is used to manipulate the single scaling coefficient used by AC-3 decoders that implement a common boost/cut scaling value for Dynamic Range Control. (D5..4 = ‘10’ in the bmAC3Features field of the AC-3 format-specific descriptor.) If this Control is addressed on a non-‘10’ decoder, the control pipe must indicate a stall. The Scaling Control can support all possible Control attributes (CUR, MIN, MAX, and RES). The valid range for the CUR, MIN, MAX, and RES attributes is from zero (0x00) to 255/256 (0xFF). The Scaling Control honors the request to the best of its abilities. It may round the bScale attribute value to its closest available setting. It will report this rounded setting when queried during a Get AC-3 Control request. Table 2-21 Scaling Control Parameter Block Control Selector AC_SCALING_CONTROL wLength 1 Offset Field Size Value Description 0 bScale 1 Number The setting for the attribute of the Scaling Control. 2.3.8.2.2.3.4 High/Low Scaling Control The High/Low Scaling Control is used to manipulate the two scaling coefficients used by AC-3 decoders that implement an independent boost and cut scaling value for Dynamic Range Control. (D5..4 = ‘11’ in the bmAC3Features field of the AC-3 format-specific descriptor.) If this Control is addressed on a non- ‘11’ decoder, the control pipe must indicate a stall. The High/Low Scaling Control can support all possible Control attributes (CUR, MIN, MAX, and RES). The valid range for the CUR, MIN, MAX, and RES attributes is from zero (0x00) to 255/256 (0xFF). The High/Low Scaling Control honors the request to the best of its abilities. It may round the bLowScale and bHighScale attribute values to their closest available settings. It will report these rounded settings when queried during a Get AC-3 Control request. The bLowScale value is used by the AC-3 decoder to scale the Dynamic Range control words which apply a gain increase (for low sound levels). The bHighScale value is used by the AC-3 decoder to scale the Dynamic Range control words which apply a gain reduction (for high level sounds). Table 2-22 High/Low Scaling Control Parameter Block Control Selector AC_HILO_SCALING_CONTROL wLength 2 1 - 6 - 11 - 16 - 21 - 26 - 31 ここを編集
https://w.atwiki.jp/usb_audio/pages/57.html
原文：Audio Devices Rev. 2.0 Spec and Adopters Agreement(ZIP) USB Device Class Definition for Audio Devices Release 2.0 May 31, 2006 11 Table A-16 Decoder Type Codes.......................................................................................135 Table A-17 Clock Source Control Selectors....................................................................135 Table A-18 Clock Selector Control Selectors..................................................................136 Table A-19 Clock Multiplier Control Selectors.................................................................136 Table A-20 Terminal Control Selectors............................................................................136 Table A-21 Mixer Control Selectors..................................................................................136 Table A-22 Selector Control Selectors.............................................................................137 Table A-23 Feature Unit Control Selectors......................................................................137 Table A-24 Reverberation Effect Unit Control Selectors................................................138 Table A-25 Reverberation Effect Unit Control Selectors................................................138 Table A-26 Modulation Delay Effect Unit Control Selectors..........................................139 Table A-27 Dynamic Range Compressor Effect Unit Control Selectors.......................139 Table A-28 Up/Down-mix Processing Unit Control Selectors........................................140 Table A-29 Dolby Prologic Processing Unit Control Selectors.....................................140 Table A-30 Stereo Extender Processing Unit Control Selectors...................................141 Table A-31 Extension Unit Control Selectors..................................................................141 Table A-32 AudioStreaming Interface Control Selectors...............................................141 Table A-33 Encoder Control Selectors.............................................................................142 Table A-34 MPEG Decoder Control Selectors.................................................................142 Table A-35 AC-3 Decoder Control Selectors....................................................................143 Table A-36 WMA Decoder Control Selectors...................................................................143 Table A-37 DTS Decoder Control Selectors.....................................................................143 Table A-38 Endpoint Control Selectors............................................................................144 USB Device Class Definition for Audio Devices Release 2.0 May 31, 2006 12 List of Figures Figure 3-1 Audio Function Global View..............................................................................18 Figure 3-2 Inside the Audio Function.................................................................................25 Figure 3-3 Input Terminal Icon............................................................................................28 Figure 3-4 Output Terminal Icon.........................................................................................29 Figure 3-5 Mixer Unit Icon....................................................................................................29 Figure 3-6 Selector Unit Icon...............................................................................................30 Figure 3-7 Feature Unit Icon................................................................................................30 Figure 3-8 Sampling Rate Converter Unit Icon..................................................................31 Figure 3-9 PEQS Effect Unit Icon........................................................................................32 Figure 3-10 Reverberation Effect Unit Icon........................................................................32 Figure 3-11 Modulation Delay Effect Unit Icon..................................................................33 Figure 3-12 Dynamic Range Compressor Transfer Characteristic.................................33 Figure 3-13 Dynamic Range Compressor Effect Unit Icon...............................................33 Figure 3-14 Up/Down-mix Processing Unit Icon...............................................................34 Figure 3-15 Dolby Prologic Processing Unit Icon.............................................................35 Figure 3-16 Stereo Extender Processing Unit Icon...........................................................35 Figure 3-17 Extension Unit Icon..........................................................................................36 Figure 3-18 Clock Source Icon............................................................................................37 Figure 3-19 Clock Selector Icon..........................................................................................37 Figure 3-20 Clock Multiplier Icon........................................................................................37 Figure 4-1 Mixer internals....................................................................................................56 USB Device Class Definition for Audio Devices Release 2.0 May 31, 2006 13 1 Introduction 1.1 Scope The Audio Device Class Definition applies to all devices or functions embedded in composite devices that are used to manipulate audio, voice, and sound-related functionality. This includes both audio data (analog and digital) and the functionality that is used to directly control the audio environment, such as Volume and Tone Control. The Audio Device Class does not include functionality to operate transport mechanisms that are related to the reproduction of audio data, such as tape transport mechanisms or CD-ROM drive control. Handling of MIDI data streams over the USB is directly related to audio and thus covered in this document. 1.2 Purpose The purpose of this document is to describe the minimum capabilities and characteristics an audio device must support to comply with the USB. This document also provides recommendations for optional features. 1.3 Related Documents • Universal Serial Bus Specification, Revision 2.0 (referred to in this document as the USB Specification). In particular, see Chapter 5, “USB Data Flow Model” and 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/52A Aug. 20, 2001. (available from Error! Hyperlink reference not valid.) • ANSI/IEEE-754 floating-point standard. • ISO/IEC 60958 International Standard Digital Audio Interface and Annexes. • ISO/IEC 61937 standard. 1.4 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 Channel Cluster Group of logical audio channels that carry tightly related synchronous audio information. A stereo audio stream is a typical example of a two-channel audio channel cluster. Audio Control Attribute Parameter of an Audio Control. Examples are Current, Minimum, Maximum and Resolution attributes of a Volume Control. Audio Control Logical object that is used to manipulate a specific audio property. Examples are Volume Control, Mute Control, etc. Audio data stream Transport medium that can carry audio information. USB Device Class Definition for Audio Devices Release 2.0 May 31, 2006 14 Audio Function Independent part of a USB device that deals with audio-related functionality. Audio Interface Collection (AIC) Grouping of a single AudioControl interface, zero or more AudioStreaming interfaces and zero or more MIDIStreaming interfaces that together constitute a complete interface to an audio function. AudioControl interface (ACI) USB interface used to access the Audio Controls inside an audio function. AudioStreaming interface (ASI) USB interface used to transport audio streams into or out of the audio function. Effect Unit (EU) Provides advanced audio manipulation on the incoming logical audio channels. Entity Addressable logical object inside an audio function. Extension Unit (XU) Applies an undefined process to a number of logical input channels. Feature Unit (FU) Provides basic audio manipulation on the incoming logical audio channels. FUD Acronym for Feature Unit Descriptor. Input Pin Logical input connection to an Entity. Carries a single audio channel cluster. Input Terminal (IT) Receptacle for audio information flowing into the audio function. ITD Acronym for Input Terminal Descriptor. Logical Audio Channel Logical transport medium for a single audio channel. Makes abstraction of the physical properties and formats of the connection. Is usually identified by spatial location. Examples are Left channel, Right Surround channel, etc. MIDIStreaming interface (MSI) USB interface that may be used to transport MIDI data streams into or out of the audio function. Mixer Unit (MU) Mixes a number of logical input channels into a number of logical output channels. MUD Acronym for Mixer Unit Descriptor. OTD Acronym for Output Terminal Descriptor. Output Pin Logical output connection to an Entity. Carries a single audio channel cluster. Output Terminal (OT) An outlet for audio information flowing out of the audio function. Processing Unit (PU) Applies a predefined process to a number of logical input channels. PUD Acronym for Processing Unit Descriptor. Selector Unit (SU) Selects from a number of input audio channel clusters. SUD Acronym for Selector Unit Descriptor. USB Device Class Definition for Audio Devices Release 2.0 May 31, 2006 15 Terminal Addressable logical object inside an audio function that represents a connection to the audio function’s outside world. Unit Addressable logical object inside an audio function that represents a certain audio subfunctionality. XUD Acronym for Extension Unit Descriptor. 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/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/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/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/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/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 ここを編集
https://w.atwiki.jp/gr-digital/pages/14.html
GR DIGITAL II 【送料無料】GR DIGITAL が更に進化！RICOH GR DIGITAL II GR DIGITAL II GR DIGITALII 1000万画素デジタルカメラ ... 関連記事 #blogsearch2