約 3,540,517 件
https://w.atwiki.jp/macmini/pages/26.html
■ OSXの64bit対応について OSXでは4GB以上のメモリを使用でき、内部も一部64bit化がされている。しかしながら、完全に64bit化するのはOSX 10.6 Snow Leopardからで、10.5まではカーネル及びデバイスドライバも32bitのままである。 参考資料 Road to Mac OS X 10.6 Snow Leopard 64-Bits Windows XPやVistaの例から32bit OSでは扱えるメモリは4GB(使用するチップセットによっては約3.3GB)までという認識が広まっているが、CPUがPAE(Physical Address Extension)、及びチップセット、OSが4GB以上のアクセスに対応していれば、32bit OSでも最大64GBまでのメモリを扱うことができる。 Windowsの例を挙げると32bit版Serverエディションの、Windows 2000 Advance Server以降、Windows 2003 Enterprise Server以降、Windows 2008 Enterprise Server以降が該当する。 OSXも同様の事を行っており、Mac mini Early 2006, Late 2006 に搭載された32bit CPUのCore Solo、Core Duoは、PAE機能によりメモリは36bitアクセス(64GB)が可能で、4GB以上のメモリを扱う事ができる。しかしながら、これらCPUと組み合わせられたチップセット945GMEの最大メモリ量は4GBまでの制限があり、更にMemory Recalim(Memory Remap)機能にも対応していない為、最大メモリ量は実質3.3GB止まりのままであった。 その後、Core 2 Duo以降の64bit CPUが採用された機種では、64bit CPU用に新たに用意された32bit互換モードでカーネル/デバイスドライバを動作させる一方で、I/OKitを64bit化させることにより、アプリケーションが扱えるメモリは64bit CPUで実装された48bit(256TB)アクセスを行い、4GB以上のメモリを扱えるようにした。 ただし、Core 2 Duoを採用したMid 2007モデルは、CPUは64bitに対応しているが、チップセットが更新されなかった為、メモリの上限は3.3GBのままである。 従って、OSX 10.4から10.5では、メモリを4GB以上搭載することもでき、周辺機器も64bit用ドライバを用意せずともそのまま使用できる。 しかしながら、Early 2009で採用したチップセットGeForce 9400Mは、最大メモリ量が8GB(DDR2使用時は16GB)になり、Memory Recalim機能にも対応している為、メモリ4GB搭載時に4GB全て使用できるようになった。 ただし、これには使用するOSに条件があり、OSの最大サポートメモリ量が物理メモリ(4GB)+メモリホール量(約700MB)の総計に対応している場合、つまり、0S自体が4GB越えに対応している必要があり、4GBまでしか扱えないWindows XP/Vista/7の32bitでは、4GB搭載しても3.3GBまでしか扱えない。 したがって、Mac mini (Early 2009)で4GB搭載時に全て使用できる (Appleがサポートしているのは太字のみ)のは以下である。 4GB以上扱えるOS Apple Microsoft その他 32bit Tiger 10.4, Leopard 10.5 Snow Leopard 10.6 Windows 2000 Advance Server以降, Windows 2003 Enterprise Server以降,Windows 2008 Enterprise Server以降 Linux (PAEカーネル/例 Ubuntu 9.10 linux-generic-paeパッケージ追加) 64bit Snow Leopard 10.6 Windows XP x64, Windows Vista 64bit, Windows 7 64bit,Windows 2003 Server x64以降, Windows 2008 Server x64以降, Windows 2008 Server R2 Linux 64 ■結論 OSX Tiger、Leopardの正体は32bitカーネルを採用し、一部のライブラリ、コマンドが64bitに対応しているだけで、4GB以上のメモリを扱うことができる32bit OSである。Snow Leopardではカーネルの他、ライブラリ、アプリケーションフレームワークのCocoaも64bit化され、完全な64bit化が図られる。 なお、従来の32bitのみのCPUもサポートするため、i386とPower PCのコードを混在させたユニバーサルバイナリと同様の仕組みで、カーネルもデバイスドライバも32bit (i386) / 64bit (x86_x64)両方のバイナリコードを含んだユニバーサルバイナリで対応する。 開発版のSnow Leopardの情報を見ると、CPUが64bitに対応していれば、起動時にデフォルトで64bitカーネルをロード、そうでなければ32bitカーネルをロードしている。デバイスドライバも同様である。 Snow Leopardのカーネル $ file /mach_kernel /mach_kernel Mach-O universal binary with 3 architectures /mach_kernel (for architecture x86_64) Mach-O 64-bit executable x86_64 /mach_kernel (for architecture i386) Mach-O executable i386 /mach_kernel (for architecture ppc) Mach-O executable ppc Leopardのカーネル $ file /mach_kernel /mach_kernel Mach-O universal binary with 2 architectures /mach_kernel (for architecture i386) Mach-O executable i386 /mach_kernel (for architecture ppc) Mach-O executable ppc ■追記. (2009/09/07) リリースされたSnow LeopardはXServeを除きデフォルトでは64bitカーネルはロードされない。64bitで起動させる為には、キーボードの「6」、「4」を同時に押して電源を入れるか、カーネルへの起動オプションとして、arch=x86_64を指定する必要がある。 しかしながら、カーネルブートローダ(boot.efi)内では機種を判別し、Mac mini、Mac Book、Mac Book Airなどの一部の機種では64bitカーネルをロードしないよう意図的に制限がかかっており、H/W(CPU、EFI)が64bit対応していても64bitカーネルは使用できない。 64bitカーネルのロード制限はブートローダによるソフトウエア制限なので、Appleの保証外になるがこちらの方法で解除可能である。 戻る
https://w.atwiki.jp/usb_audio/pages/33.html
原文：Audio Device Document 1.0(PDF) USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 26 · Reverb Level sets the amount of reverberant sound. · Reverb Time sets the time over which the reverberation will continue. · Reverb Delay Feedback used with Reverb Types Delay and Delay Panning. Sets the way in which delay repeats The effects of the Reverberation Processing Unit can be bypassed at all times through manipulation of the Enable Processing Control. In principle, the algorithm to produce the desired reverberation effect influences all channels as a whole. It is entirely left to the designer how a certain reverberation effect is obtained. It is not the intention of this specification to precisely define all the parameters that influence the reverberation experience (for instance in a multi-channel system, it is possible to create very similar reverberation impressions, using different algorithms and parameter settings on all channels). The symbol for the Reverberation Processing Unit can be found in the following figure ここに画像 Figure 3-9 Reverberation Processing Unit Icon 3.5.6.5 Chorus Processing Unit The Chorus Processing Unit is used to add chorus effects to the original audio information. A number of parameters can be manipulated to obtain the desired chorus effects. · Chorus Level controls the amount of the effect sound of chorus. · Chorus Modulation Rate sets the speed (frequency) of the modulator of the chorus. · Chorus Modulation Depth sets the depth at which the chorus sound is modulated. The effects of the Chorus Processing Unit can be bypassed at all times through manipulation of the Enable Processing Control. In principle, the algorithm to produce the desired chorus effect influences all channels as a whole. It is entirely left to the designer how a certain chorus effect is obtained. It is not the intention of this specification to precisely define all the parameters that influence the chorus experience. The symbol for the Chorus Processing Unit can be found in the following figure ここに画像 Figure 3-10 Chorus Processing Unit Icon 3.5.6.6 Dynamic Range Compressor Processing Unit The Dynamic Range Compressor Processing Unit is used to intelligently limit the dynamic range of the original audio information. A number of parameters can be manipulated to influence the desired compression. USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 27 ここに画像 Figure 3-11 Dynamic Range Compressor Transfer Characteristic · Compression ratio R determines the slope of the static input-to-output transfer characteristic in the compressor’s active input range. The compression is defined in terms of the compression ratio R, which is the inverse of the derivative of the output power PO as a function of the input power PI when PO and PI are expressed in dB. 数式 PR is the reference level and it is made equal to the so-called line level. All levels are expressed relative to the line level (0 dB), which is usually 15-20 dB below the maximum level. Compression is obtained when R 1, R = 1 does not affect the signal and R 1 gives rise to expansion. · Maximum Amplitude the upper boundary of the active input range, relative to the line level (0 dB). Expressed in dB. · Threshold level the lower boundary of the active input level, relative to the line level (0 dB). · Attack Time determines the response of the compressor as a function of time to a step in the input level. Expressed in ms. · Release Time relates to the recovery time of the gain of the compressor after a loud passage. Expressed in ms. The effects of the Dynamic Range Compressor Processing Unit can be bypassed at all times through manipulation of the Enable Processing Control. In principle, the algorithm to produce the desired dynamic range compression influences all channels as a whole. It is entirely left to the designer how a certain dynamic range compression is obtained. The symbol for the Dynamic Range Compressor Processing Unit can be found in the following figure ここに画像 {Figure 3-12 Dynamic Range Compressor Processing Unit Icon｝｝ USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 28 3.5.7 Extension Unit The Extension Unit (XU) is the method provided by this specification to easily add vendor-specific building blocks to the specification. The Extension Unit provides one or more logical input channels, grouped into one or more audio channel clusters and transforms them into a number of logical output channels, grouped into one audio channel cluster. Therefore, the Extension Unit can have multiple Input Pins and has a single Output Pin. Extension Units are required to support at least the Enable Processing Control, allowing the Host software to bypass whatever functionality is incorporated in the Extension Unit. Although a generic audio driver will not be able to determine what functionality is implemented in the Extension Unit, let alone manipulate it, it still will be capable of recognizing the presence of vendorspecific extensions and assume default behavior for those units. The symbol for the Extension Unit can be found in the following figure ここに画像 {Figure 3-13 Extension Unit Icon 3.5.8 Associated Interfaces In some cases, an audio function building block (Terminal, Mixer Unit, Feature Unit, and so on) needs to be associated with interfaces that are not part of the Audio Interface Collection. As an example, consider a speaker system with front-panel volume knob. The manufacturer might want to impose a binding between the front-panel volume Control and the speaker system’s volume setting. The volume knob could be represented by a HID interface that coexists with the Audio Interface Collection. To create a binding between the Feature Unit inside the audio function that deals with master Volume Control and the frontpanel volume knob, the Feature Unit descriptor can be supplemented by a special Associated Interface descriptor that holds a link to the associated HID interface. In general, each Terminal or Unit descriptor can be supplemented by one or more optional Associated Interface descriptors that hold a reference to an interface. This interface is external to the audio function and interacts in a certain way with the Terminal or Unit. The layout of the Associated Interface descriptor is open-ended and is qualified by the Entity type it succeeds and by the target interface Class type it references. For the time being, this specification does not define any specific Associated Interface descriptor layout. 3.6 Copy Protection Because the Audio Device Class is primarily dealing with digital audio streams, the issue of protecting these – often-copyrighted – streams can not be ignored. Therefore, this specification provides the means to preserve whatever copyright information is available. However, it is the responsibility of the Host software to manage the flow of copy protection information throughout the audio function. Copy protection issues come into play whenever digital audio streams enter or leave the audio function. Therefore, the copy protection mechanism is implemented at the Terminal level in the audio function. Streams entering the audio function can be accompanied by specific information, describing the copy protection level of that audio stream. Likewise, streams leaving the audio function should be accompanied by the appropriate copy protection information, if the hardware permits it. This specification provides for two dedicated requests that can be used to manage the copy protection mechanism. The Get Copy Protect USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 29 request can be used to retrieve copy protection information from an Input Terminal whereas the Set Copy Protect request is used to preset the copy protection level of an Output Terminal. This specification provides for three levels of copy permission, similar to CGMS (Copy Generation Management System) and SCMS (Serial Copy Management System). · Level 0 Copying is permitted without restriction. The material is either not copyrighted, or the copyright is not asserted. · Level 1 One generation of copies may be made. The material is copyright protected and is the original. · Level 2 The material is copyright protected and no digital copying is permitted. 3.7 Operational Model A device can support multiple configurations. Within each configuration can be multiple interfaces, each possibly having alternate settings. These interfaces can pertain to different functions that co-reside in the same composite device. Even several independent audio functions can exist in the same device. Interfaces, belonging to the same audio function are grouped into an Audio Interface Collection. If the device contains multiple independent audio functions, there must be multiple Audio Interface Collections, each providing full access to their associated audio function. As an example of a composite device, consider a PC monitor equipped with a built-in stereo speaker system. Such a device could be configured to have one interface dealing with configuration and control of the monitor part of the device (HID Class), while a Collection of two other interfaces deals with its audio aspects. One of those, the AudioControl interface, is used to control the inner workings of the function (Volume Control etc.) whereas the other, the AudioStreaming interface, handles the data traffic, sent to the monitor’s audio subsystem. The AudioStreaming interface could be configured to operate in mono mode (alternate setting x) in which only a single channel data stream is sent to the audio function. The receiving Input Terminal could duplicate this audio stream into two logical channels, and those could then be reproduced on both speakers. From an interface point of view, such a setup requires one isochronous endpoint in the AudioStreaming interface to receive the mono audio data stream, in addition to the mandatory control endpoint and optional interrupt endpoint in the AudioControl interface. The same system could be used to play back stereo audio. In this case, the stereo AudioStreaming interface must be selected (alternate setting y). This interface also consists of a single isochronous endpoint, now receiving a data stream that interleaves left and right channel samples. The receiving Input Terminal now splits the stream into a Left and Right logical channel. The AudioControl interface remains unchanged. If the above AudioStreaming interface were an asynchronous sink, one extra isochronous synch endpoint would also be necessary. Audio Interface Collections can be dynamic. Because the AudioControl interface, together with its associated AudioStreaming interface(s), constitute the ‘logical interface’ to the audio function, they must all come into existence at the same moment in time. As stated earlier, audio functionality is located at the interface level in the device class hierarchy. The following sections describe the Audio Interface Collection, containing a single AudioControl interface and optional AudioStreaming interfaces, together with their associated endpoints that are used for audio function control and for audio data stream transfer. USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 30 3.7.1 AudioControl Interface To control the functional behavior of a particular audio function, the Host can manipulate the Units and Terminals inside the audio function. To make these objects accessible, the audio function must expose a single AudioControl interface. This interface can contain the following endpoints · A control endpoint for manipulating Unit and Terminal settings and retrieving the state of the audio function. This endpoint is mandatory, and the default endpoint 0 is used for this purpose. · An interrupt endpoint for status returns. This endpoint is optional. The AudioControl interface is the single entry point to access the internals of the audio function. All requests that are concerned with the manipulation of certain audio Controls within the audio function’s Units or Terminals must be directed to the AudioControl interface of the audio function. Likewise, all descriptors related to the internals of the audio function are part of the class-specific AudioControl interface descriptor. The AudioControl interface of an audio function may support multiple alternate settings. Alternate settings of the AudioControl interface could for instance be used to implement audio functions that support multiple topologies by presenting different class-specific AudioControl interface descriptors for each alternate setting. 3.7.1.1 Control Endpoint The audio interface class uses endpoint 0 (the default pipe) as the standard way to control the audio function using class-specific requests. These requests are always directed to one of the Units or Terminals that make up the audio function. The format and contents of these requests are detailed further in this document. 3.7.1.2 Status Interrupt Endpoint A USB AudioControl interface can support an optional interrupt endpoint to inform the Host about the status the status of the different addressable Entities (Terminals, Units, interfaces and endpoints) inside the audio function. In fact, the interrupt endpoint is used by the entire Audio Interface Collection to convey status information to the Host. It is considered part of the AudioControl interface because this is the anchor interface for the Collection. The interrupt data is a 2-byte entity. The bStatusType field contains information in D7 indicating whether there is still an interrupt pending or not. This bit remains set until all pending interrupts are properly serviced. The other bits are used to report the cause of the interrupt in more detail. Bit D6 of the bStatusType field indicates a change in memory contents on one of the addressable Entities inside the audio function. This bit is cleared by a Get Memory request on the appropriate Entity. Bits D3..0 indicate the originator of the current interrupt. All addressable Entities inside an audio function can be originator. The contents of the bOriginator field must be interpreted according to the code in D3..0 of the bStatusType field. If the originator is the AudioControl interface, the bOriginator field contains the TerminalID or UnitID of the Entity that caused the interrupt to occur. If the bOriginator field is set to zero, the ‘virtual’ Entity interface is the originator. This can be used to report global AudioControl interface changes to the Host. If the originator is an AudioStreaming interface, the bOriginator field contains the interface number of the AudioStreaming interface. Likewise, it contains the endpoint number if the originator were an AudioStreaming endpoint. The proper response to an interrupt is either a Get Status request (D6=0) or a Get Memory request (D6=1). Issuing these requests to the appropriate originator must clear the Interrupt Pending bit and the Memory Contents Changed bit, if applicable. The following table specifies the format of the status word 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/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/42.html
原文：Audio Device Document 1.0(PDF) USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 66 5.2.1.1 Set Request This request is used to set an attribute of a Control inside an Entity of the audio function. Additionally, the memory space attribute of an Entity itself can be set through this request. Table 5-1 Set Request Values bmRequest Type bRequest wValue wIndex wLength Data 00100001B Entity ID and Interface 00100010B SET_CUR SET_MIN SET_MAX SET_RES SET_MEM See following paragraphs Endpoint Length of parameter block Parameter block The bmRequestType field specifies that this is a SET request (D7=0b0). It is a class-specific request (D6..5=0b01), directed to either the AudioControl interface or an AudioStreaming interface of the audio function (D4..0=0b00001) or the isochronous endpoint of an AudioStreaming interface (D4..0=0b00010). The bRequest field contains a constant, identifying which attribute of the addressed Control or Entity is to be modified. Possible attributes for a Control are its · Current setting attribute (SET_CUR) · Minimum setting attribute (SET_MIN) · Maximum setting attribute (SET_MAX) · Resolution attribute (SET_RES) Possible attributes for an Entity are its · Memory space attribute (SET_MEM) If the addressed Control or Entity does not support modification of a certain attribute, the control pipe must indicate a stall when an attempt is made to modify that attribute. In most cases, only the CUR and MEM attribute will be supported for the Set request. However, this specification does not prevent a designer from making other attributes programmable. For the list of Request constants, refer to Section A.9, “Audio Class-Specific Request Codes.” The wValue field interpretation is qualified by the value in the wIndex field. Depending on what Entity is addressed, the layout of the wValue field changes. The following paragraphs describe the contents of the wValue field for each Entity separately. In most cases, the wValue field contains the Control Selector (CS) in the high byte. It is used to address a particular Control within Entities that can contain multiple Controls. If the Entity only contains a single Control, there is no need to specify a Control Selector and the wValue field can be used to pass additional parameters. The wIndex field specifies the interface or endpoint to be addressed in the low byte and the Entity ID or zero in the high byte. In case an interface is addressed, the virtual Entity ‘interface’ can be addressed by specifying zero in the high byte. The values in wIndex must be appropriate to the recipient. Only existing Entities in the audio function can be addressed and only appropriate interface or endpoint numbers may be used. If the request specifies an unknown or non-Entity ID or an unknown interface or endpoint number, the control pipe must indicate a stall. The actual parameter(s) for the Set request are passed in the data stage of the control transfer. The length of the parameter block is indicated in the wLength field of the request. The layout of the parameter block is qualified by both the bRequest and wIndex fields. Refer to the following sections for a detailed description of the parameter block layout for all possible Entities. USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 67 5.2.1.2 Get Request This request returns the attribute setting of a specific Control inside an Entity of the audio function. Additionally, the memory space attribute of an Entity itself can be returned through this request. Table 5-2 Get Request Values bmRequest Type bRequest wValue wIndex wLength Data 10100001B Entity ID and Interface 10100010B GET_CUR GET_MIN GET_MAX GET_RES GET_MEM See following paragraphs Endpoint Length of parameter block Parameter block The bmRequestType field specifies that this is a GET request (D7=0b1). It is a class-specific request (D6..5=0b01), directed to either the AudioControl interface or an AudioStreaming interface of the audio function (D4..0=0b00001) or the isochronous endpoint of an AudioStreaming interface (D4..0=0b00010). The bRequest field contains a constant, identifying which attribute of the addressed Control or Entity is to be returned. Possible attributes for a Control are its · Current setting attribute (GET_CUR) · Minimum setting attribute (GET_MIN) · Maximum setting attribute (GET_MAX) · Resolution attribute (GET_RES) Possible attributes for an Entity are its · Memory space attribute (GET_MEM) If the addressed Control or Entity does not support readout of a certain attribute, the control pipe must indicate a stall when an attempt is made to read that attribute. For the list of Request constants, refer to Section A.9, “Audio Class-Specific Request Codes.” The wValue field interpretation is qualified by the value in the wIndex field. Depending on what Entity is addressed, the layout of the wValue field changes. The following paragraphs describe the contents of the wValue field for each Entity separately. In most cases, the wValue field contains the Control Selector (CS) in the high byte. It is used to address a particular Control within Entities that can contain multiple Controls. If the Entity only contains a single Control, there is no need to specify a Control Selector and the wValue field can be used to pass additional parameters. The wIndex field specifies the interface or endpoint to be addressed in the low byte and the Entity ID or zero in the high byte. In case an interface is addressed, the virtual Entity ‘interface’ can be addressed by specifying zero in the high byte. The values in wIndex must be appropriate to the recipient. Only existing Entities in the audio function can be addressed and only appropriate interface or endpoint numbers may be used. If the request specifies an unknown or non-Entity ID or an unknown interface or endpoint number, the control pipe must indicate a stall. The actual parameter(s) for the Get request are returned in the data stage of the control transfer. The length of the parameter block to return is indicated in the wLength field of the request. If the parameter block is longer than what is indicated in the wLength field, only the initial bytes of the parameter block are returned. If the parameter block is shorter than what is indicated in the wLength field, the device indicates the end of the control transfer by sending a short packet when further data is requested. The layout of the parameter block is qualified by both the bRequest and wIndex fields. Refer to the following sections for a detailed description of the parameter block layout for all possible Entities. USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 68 5.2.2 AudioControl Requests The following sections describe the possible requests that can be used to manipulate the audio Controls an audio function exposes through its Units. The same layout of the parameter blocks is used for both the Set and Get requests. 5.2.2.1 Terminal Control Requests The following paragraphs describe the Set and Get Terminal Control requests. 5.2.2.1.1 Set Terminal Control Request This request is used to set an attribute of a Terminal Control inside a Terminal of the audio function. Table 5-3 Set Terminal Control Request Values bmRequest Type bRequest wValue wIndex wLength Data 00100001B SET_CUR SET_MIN SET_MAX SET_RES CS Terminal ID 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. 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 Terminal, the control pipe must indicate a stall. For a description of the parameter block for the Terminal Controls, see Section 5.2.2.1.3, “Terminal Controls.” 5.2.2.1.2 Get Terminal Control Request This request returns the attribute setting of a specific Terminal Control inside a Terminal of the audio function. Table 5-4 Get Terminal Control Request Values bmRequest Type bRequest wValue wIndex wLength Data 10100001B GET_CUR GET_MIN GET_MAX GET_RES CS Terminal ID 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 Terminal, the control pipe must indicate a stall. For a description of the parameter block for the Terminal Controls, see Section 5.2.2.1.3, “Terminal Controls.” USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 69 5.2.2.1.3 Terminal Controls For the time being, this specification defines only one Terminal Control. The following section presents a detailed description. 5.2.2.1.3.1 Copy Protect Control The Copy Protect Control is used to manipulate the Copy Protection Level (CPL) associated with a particular Terminal. Not all Terminals are required to support this Control. Only the Terminals that represent a connection to the audio function where audio streams enter or leave the audio function in a form that enables lossless duplication should consider Copy Protect Control. Input Terminals in this category should only support the Get Terminal Copy Protect Control request whereas Output Terminals in the same category should only support the Set Terminal Copy Protect Control request. A Copy Protect Control only supports the CUR attribute. The settings for the CUR attribute range from 0 to 2. This means · 0 CPL0 Copying is permitted without restriction. The material is either not copyrighted, or the copyright is not asserted. · 1 CPL1 One generation of copies may be made. The material is copyright protected and is the original. · 2 CPL2 The material is copyright protected and no digital copying is permitted. The Copy Protect Control honors the request to the best of its abilities. It may round the bCopyProtect attribute value to its closest available setting. It will report this setting when queried during a Get Control request. Table 5-5 Copy Protect Control Parameter Block Control Selector COPY_PROTECT_CONTROL wLength 1 Offset Field Size Value Description 0 bCopyProtect 1 Number The setting for the CUR attribute of the CopyProtect Control. 0x00 CPL0 0x01 CPL1 0x02 CPL2 5.2.2.2 Mixer Unit Control Requests The following paragraphs describe the Set and Get Mixer Unit Control requests. The Set Mixer Unit Control request can have two forms. The first form must be supported while the second form can be optionally implemented. The Get Mixer Unit Control request can have three forms. The first form must be supported, while the second and third form can be optionally implemented. If the second form of the Set request is implemented, the second form of the Get request must also be implemented. USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 70 5.2.2.2.1 Set Mixer Unit Control Request This request is used to set an attribute of a Mixer Control inside a Mixer Unit of the audio function. Table 5-6 Set Mixer Unit Control Request Values bmRequest Type bRequest wValue wIndex wLength Data 00100001B SET_CUR SET_MIN SET_MAX SET_RES ICN and OCN Mixer Unit ID 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. Because the Mixer Unit only contains a single type of Control, there is no need for a Control Selector. Instead, the wValue field specifies the Input Channel Number (ICN) in the high byte and the Output Channel Number (OCN) in the low byte of the Mixer Control to be influenced. The ICN is derived from both the input cluster number and the logical channel number within that cluster, according to the rules established in Section 4.3.2.3, “Mixer Unit Descriptor.” (ICN=u, OCN=v) If the request specifies an unknown ICN or OCN to that Unit or refers to a non-programmable Mixer Control in the Mixer Unit, the control pipe must indicate a stall. A special case arises when the Input Channel Number and Output Channel Number are both set to 0xFF. Then a single Set Mixer Unit Control request can be used to set an attribute of all the programmable Mixer Controls within the Unit. The number of parameters passed in the parameter block must exactly match the number of programmable Mixer Controls in the Unit. If this is not the case, the control pipe must indicate a stall. The ordering of the parameters in the parameter block obeys the same rules as established for the bit ordering in the bmControls field of the Mixer Unit Descriptor. The parameter block must contain an attribute setting for every Mixer Control that has its bit set in the bmControls field. The previous description is referred to as the second form of the Set Mixer Unit Control request. For a description of the parameter block for the Set Mixer Unit Control request, see Section 5.2.2.2.3, “Mixer Control.” 5.2.2.2.2 Get Mixer Unit Control Request This request returns the attribute setting of a specific Mixer Control inside a Mixer Unit of the audio function. Table 5-7 Get Mixer Unit Control Request Values bmRequest Type bRequest wValue wIndex wLength Data 10100001B GET_CUR GET_MIN GET_MAX GET_RES ICN and OCN Mixer Unit ID and Interface Length of parameter block Parameter block The bRequest field indicates which attribute the request is reading Because the Mixer Unit only contains a single type of Control, there is no need for a Control Selector. Instead, the wValue field specifies the Input Channel Number (ICN) in the high byte and the Output Channel Number (OCN) in the low byte of the Mixer Control to be retrieved. The ICN is derived from both the input cluster number and the logical channel number within that cluster, according to the rules 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/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/24.html
原文：Audio Data Formats 1.0(PDF) USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 26 Offset Field Size Value Description 0 bLowScale 1 Number The setting for the attribute of the lowlevel Scaling Control. 1 bHighScale 1 Number The setting for the attribute of the highlevel Scaling Control. 2.4 Type III Formats These formats are based upon the IEC1937 standard. The IEC1937 standard describes a method to transfer non-PCM encoded audio bitstreams over an IEC958 digital audio interface, together with the transfer of the accompanying “Channel Status” and “User Data.” The IEC958 standard specifies a widely used method of interconnecting digital audio equipment with twochannel linear PCM audio. The IEC1937 standard describes a way in which the IEC958 interface shall be used to convey non-PCM encoded audio bit streams for consumer applications. The same basic techniques used in IEC1937 are reused here to convey non-PCM encoded audio bit streams over a Type III formatted audio stream. 2.4.1 Type III Format Type Descriptor The Type III Format Type is identical to the Type I PCM Format Type, set up for two-channel 16-bit PCM data. It therefore uses two audio subframes per audio frame. The subframe size is two bytes and the bit resolution is 16 bits. The Type III Format Type descriptor is identical to the Type I Format Type descriptor but with the bNrChannels field set to two, the bSubframeSize field set to two and the bBitResolution field set to 16. All the techniques used to correctly transport Type I PCM formatted streams over USB equally apply to Type III formatted streams. The non-PCM encoded audio bitstreams that are transferred within the basic 16-bit data area of the IEC1937 subframes (time-slots 12 [LSB] to 27 [MSB]) are placed unaltered in the two available 16-bit audio subframes per audio frame of the Type III formatted USB stream. The additional information in the IEC1937 subframes (channel status, user bits etc.) is discarded. Refer to the IEC1937 standard for a detailed description of the exact contents of the subframes. The layout of the Type III Format Type descriptor is given here for clarity. All preassigned fields have been filled in. Table 2-23 Type III Format Type Descriptor Offset Field Size Value Description 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_III. Constant identifying the Format Type the AudioStreaming interface is using. 4 bNrChannels 1 Number Indicates the number of ‘virtual’ physical channels in the audio data stream. Must be set to two. USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 27 Offset Field Size Value Description 5 bSubframeSize 1 Number The number of bytes occupied by one audio subframe. Must be set to 2. 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-24 Continuous Sampling Frequency Offset Field Size Value Description 8 tLowerSamFreq 3 Number Lower bound in Hz of the sampling frequency range for this isochronous data endpoint. 11 tUpperSamFreq 3 Number Upper bound in Hz of the sampling frequency range for this isochronous data endpoint. Table 2-25 Discrete Number of Sampling Frequencies Offset Field Size Value Description 8 tSamFreq [1] 3 Number Sampling frequency 1 in Hz for this isochronous data endpoint. … … … … … 8+(ns-1)*3 tSamFreq [ns] 3 Number Sampling frequency ns in Hz for this isochronous data endpoint. Note In the case of adaptive isochronous data endpoints that support only a discrete number of sampling frequencies, the endpoint must at least tolerate ±1000 PPM inaccuracy on the reported sampling frequencies. USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 28 3 Adding New Audio Data Formats Adding new Audio Data Formats to this specification is achieved by proposing a fully documented Audio Data Format to the Audio Device Class Working Group. Upon acceptance, they will register the new Audio Data Format (attribute a unique wFormatTag) and update this document accordingly. This process will also guarantee that new releases of generic USB audio drivers will support the newly registered Audio Data Formats. It is always possible to use vendor-specific definitions if the above procedure is considered unsatisfactory. USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 29 Appendix A. Additional Audio Device Class Codes A.1 Audio Data Format Codes A.1.1 Audio Data Format Type I Codes Table A-1 Audio Data Format Type I Codes Name wFormatTag TYPE_I_UNDEFINED 0x0000 PCM 0x0001 PCM8 0x0002 IEEE_FLOAT 0x0003 ALAW 0x0004 MULAW 0x0005 A.1.2 Audio Data Format Type II Codes Table A-2 Audio Data Format Type II Codes Name wFormatTag TYPE_II_UNDEFINED 0x1000 MPEG 0x1001 AC-3 0x1002 A.1.3 Audio Data Format Type III Codes Table A-3 Audio Data Format Type III Codes Name wFormatTag TYPE_III_UNDEFINED 0x2000 IEC1937_AC-3 0x2001 IEC1937_MPEG-1_Layer1 0x2002 IEC1937_MPEG-1_Layer2/3 orIEC1937_MPEG-2_NOEXT 0x2003 IEC1937_MPEG-2_EXT 0x2004 IEC1937_MPEG-2_Layer1_LS 0x2005 USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 30 Name wFormatTag IEC1937_MPEG-2_Layer2/3_LS 0x2006 A.2 Format Type Codes Table A-4 Format Type Codes Format Type Code Value FORMAT_TYPE_UNDEFINED 0x00 FORMAT_TYPE_I 0x01 FORMAT_TYPE_II 0x02 FORMAT_TYPE_II 0x03 A.3 Format-Specific Control Selectors A.3.1 MPEG Control Selectors Table A-5 MPEG Control Selectors Control Selector Value MPEG_CONTROL_UNDEFINED 0x00 MP_DUAL_CHANNEL_CONTROL 0x01 MP_SECOND_STEREO_CONTROL 0x02 MP_MULTILINGUAL_CONTROL 0x03 MP_DYN_RANGE_CONTROL 0x04 MP_SCALING_CONTROL 0x05 MP_HILO_SCALING_CONTROL 0x06 A.3.2 AC-3 Control Selectors Table A-6 AC-3 Control Selectors Control Selector Value AC_CONTROL_UNDEFINED 0x00 AC_MODE_CONTROL 0x01 AC_DYN_RANGE_CONTROL 0x02 AC_SCALING_CONTROL 0x03 1 - 6 - 11 - 16 - 21 - 26 - 31 ここを編集
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/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/kojiro/pages/23.html
EXACT TRUE, FALSE EXACT(文字列1,文字列2) 文字列1 比較する文字列 文字列2 もう一方の文字列 例 =exact("word","word")=TRUE =exact("Word","word")=FALSE =exact(a2,b2) この関数は大文字と小文字を区別するので２番目の例ではFALSE が返る。ただし、このような使い方は実用的ではない。３番目の例のようにセル参照を比較したり、動的な比較ができないと使いづらい。