約 5,030,679 件
https://w.atwiki.jp/usb_audio/pages/22.html
原文：Audio Data Formats 1.0(PDF) USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 11 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-3 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. 2.2.6 Supported Formats The following paragraphs list all currently supported Type I Audio Data Formats. 2.2.6.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 subframe. The binary point is located to the right of the sign bit so that all values lie within the range [-1,+1). 2.2.6.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 subframe, Msb first. The range is [0,255]. 2.2.6.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 USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 12 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. 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; bSubframeSize = 4). 2.2.6.4 ALaw Format and mLaw 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 subframe, Msb first. The compressed range is [-128,128]. The difference between Alaw and mLaw compression lies in the formulae used to achieve the compression. Refer to the ITU G.711 standard for further details. 2.3 Type II Formats Type II formats are used to transmit non-PCM encoded audio data into bitstreams that consist of a sequence of encoded audio frames. 2.3.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 samples. 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 samples used to construct one encoded audio frame depends on the encoding scheme. (For MPEG, the number of samples per encoded audio frame (nf) is 384 for Layer I or 1152 for Layer II. For AC-3, the number of samples 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 frame time of 1 ms. This is typical of audio compression algorithms that use psycho-acoustic or vocal tract parametric models. Note It is important to make a clear distinction between an audio frame (see Section 2.2.3, “Audio Frame”) and an encoded audio frame. The overloaded use of the term audio frame could cause confusion. Therefore, this specification will always use the qualifier ‘encoded’ to refer to MPEG or AC-3 encoded audio frames. 2.3.2 Audio Bitstreams An encoded audio bitstream 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. USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 13 2.3.3 USB Packets Encoded audio bitstreams are packetized when transported over an isochronous pipe. Each USB packet contains only part of a single encoded audio frame. Packet sizes are determined according to the shortpacket 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 USB 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 consecutive USB frames until the next encoded audio frame is due. The above rules guarantee that a new encoded audio frame always starts on a USB packet boundary. 2.3.4 Bandwidth Allocation The encoded audio frame time tf equals the number of audio samples 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 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.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 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.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 wSamplesPerFrame field contains the number of non-PCM encoded audio samples contained within a single encoded audio frame The sampling frequency capabilities of the endpoint are reported using the bSamFreqType field andfollowing fields. Table 2-4 Type II Format Type Descriptor Offset Field Size Value Description USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 14 Offset Field Size Value Description 0 bLength 1 Number Size of this descriptor, in bytes 9+(ns*3) 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 wSamplesPerFrame 2 Number Indicates the number of PCM audio samples contained in one encoded audio frame. 8 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) 9... 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-5 Continuous Sampling Frequency Offset Field Size Value Description 9 tLowerSamFreq 3 Number Lower bound in Hz of the sampling frequency range for this isochronous data endpoint. 12 tUpperSamFreq 3 Number Upper bound in Hz of the sampling frequency range for this isochronous data endpoint. Table 2-6 Discrete Number of Sampling Frequencies Offset Field Size Value Description 9 tSamFreq [1] 3 Number Sampling frequency 1 in Hz for this isochronous data endpoint. … … … … … USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 15 Offset Field Size Value Description 9+(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. 2.3.7 Rate feedback If the isochronous data endpoint needs explicit rate feedback (adaptive source, asynchronous sink), the feedback pipe shall report the number of equivalent PCM audio samples. The host will accumulate this data and start transmission of an encoded audio frame whenever the current number of samples exceeds the number of samples per encoded audio frame. The remainder is kept in the accumulator. 2.3.8 Supported Formats The following sections list all currently supported Type II Audio Data Formats. Format-specific descriptors and format-specific requests are explained in more detail. 2.3.8.1 MPEG Format In the current specification, only MPEG decoding aspects are considered. Real-time MPEG encoding peripherals are not (yet) available and consequently are not covered by this specification. 2.3.8.1.1 MPEG 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. The bmMPEGCapabilities bitmap field describes the capabilities of the MPEG decoder built into the AudioStreaming interface. Some general information must be retrieved from the Format Type-specific descriptor. For instance, the sampling frequencies supported by the decoder are reported through the Format Type-specific descriptor. This includes the ability of the decoder to handle low sampling frequencies (16 kHz, 22.05 kHz and 24 kHz) besides the standard 32 kHz, 44.1 kHz and 48 kHz sampling frequencies. Bits D2..0 of the bmMPEGCapabilities field are used to indicate which layers this decoder is capable of processing. The different layers relate to the different algorithms that are used during encoding and decoding. Bit D3 indicates that the decoder can only process the MPEG-1 base stream. Therefore, only Left and Right channels will be output. Bit D4 indicates that the decoder can handle MPEG-2 streams that contain two independent stereo pairs instead of the normal 3/2 encoding scheme. This bit is only applicable for MPEG-2 decoders. Bit D5 indicates that the decoder supports the MPEG dual channel mode. In this case, the MPEG-1 base stream does not contain Left and Right channels of a stereo pair but instead contains two independent mono channels. One of these channels can be selected through the proper request (Dual Channel Control) and reproduced over the Left and Right output channels simultaneously. Bit D6 indicates that the decoder supports the DVD MPEG-2 augmentation to 7.1 channels instead of the standard 5.1 channels. 1 - 6 - 11 - 16 - 21 - 26 - 31 ここを編集
https://w.atwiki.jp/usb_audio/pages/23.html
原文：Audio Data Formats 1.0(PDF) USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 16 Bit D6 indicates that the multilingual information that is encoded at normal sampling rates (32 kHz, 44.1 kHz or 48 kHz). This bit is only applicable for MPEG-2 decoders. Bit D7 indicates that the decoder is capable of processing streams that are encoded using adaptive multichannel prediction. Bits D9..8 indicate if the decoder can process embedded multilingual information. Multilingual capabilities can consist of being able to process multilingual information encoded at the same sampling frequency as the main audio channels (D9..8 = ‘01’). Some decoders may provide the additional capability to process multilingual information encoded at half the sampling frequency of the main audio channels (D9..8 = ‘11’). Bits D15..10 are reserved for future extensions. The bmMPEGFeatures field indicates compression-related features. Bits D5..4 report which type of Dynamic Range Control the MPEG 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-7 MPEG Format-Specific Descriptor Offset Field Size Value Description 0 bLength 1 Number Size of this descriptor, in bytes 9 1 bDescriptorType 1 Constant CS_INTERFACE descriptor type. 2 bDescriptorSubtype 1 Constant FORMAT_SPECIFIC descriptor subtype. 3 wFormatTag 2 Constant MPEG. Constant identifying the precise format the AudioStreaming interface is using. USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 17 Offset Field Size Value Description 5 bmMPEGCapabilities 2 Bitmap Bitmap identifying the MPEG capabilities of the decoder. A bit set indicates that the capability is supported D2..0 Layer support D0 = Layer ID1 = Layer IID2 = Layer IIID3 MPEG-1 only.D4 MPEG-1 dual-channel.D5 MPEG-2 second stereo.D6 MPEG-2 7.1 channel augmentation.D7 Adaptive multi-channel prediction.D9..8 MPEG-2 multilingual support 00 = Not supported01 = Supported at Fs10 = Reserved11 = Supported at Fs and ½Fs.D15..10 Reserved. 7 bmMPEGFeatures 1 Bitmap Bitmap identifying the features the decoder supports. A bit set indicates that the feature is supported D3..0 Reserved.D5..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. 2.3.8.1.2 MPEG Format-Specific Requests The following paragraphs describe the Set and Get MPEG Control requests. Some of the requests control parameters that are also dependent on the content of the incoming MPEG data stream. In general, the behavior of the MPEG decoder is primarily controlled by the incoming bitstream. Parameters set using MPEG Control requests retain their setting, even if that setting is not applicable to the current incoming bitstream. As an example, consider a decoder that is receiving a stream containing two independent stereo channel pairs. In this case, the Select Second Stereo Control can be enabled so that the second stereo channel is reproduced over the Left and Right channel. If the incoming stream is now switched to a full 5.1 encoded stream, the Select Second Stereo Control has no more influence and the decoder overrides its setting and produces full 5.1 sound. However, if the incoming stream switches back to the previous format, the Select Second Stereo Control becomes active again and resumes its previous setting so that the second stereo channel is reproduced again over the Left and Right channel. USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 18 2.3.8.1.2.1 Set MPEG Control Request This request is used to set an attribute of an MPEG Control inside an AudioStreaming interface of the audio function. Table 2-8 Set MPEG 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 plock 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.1.2.3, “MPEG 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.1.2.3, “MPEG Controls.” 2.3.8.1.2.2 Get MPEG Control Request This request returns the attribute setting of a specific MPEG Control inside an AudioStreaming interface of the audio function. Table 2-9 Get MPEG Control Request Values bmRequest Type bRequest wValue wIndex wLength Data 10100001B GET_CURGET_MINGET_MAXGET_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.1.2.3, “MPEG Controls.” 2.3.8.1.2.3 MPEG 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 appropriate Control Selector is listed. The Control Selector codes are defined in Section A.3.1, “MPEG Control Selectors.” USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 19 2.3.8.1.2.3.1 Dual Channel Control The Dual Channel Control is used to select which of the two available channels in the MPEG-1 base stream is actually retrieved and reproduced over the Left and Right output channels. If this Control is addressed on a decoder that does not implement Dual Channel Control (D4 = ‘0’ in the bmMPEGCapabilities field of the MPEG format-specific descriptor), the control pipe must indicate a stall. The Dual Channel Control can have only the current setting attribute (CUR). The position of the Channel2Enable switch can be either TRUE or FALSE. When FALSE, Channel I is selected, and when TRUE, Channel II is selected. The current setting of the Control can be queried using a Get MPEG Control request. Table 2-10 Dual Channel Control Parameter Block Control Selector MP_DUAL_CHANNEL_CONTROL wLength 1 Offset Field Size Value Description 0 BChannel2Enable 1 Number The setting for the attribute of the Dual Channel Control. Channel I selected when FALSE, Channel II selected when TRUE. 2.3.8.1.2.3.2 Second Stereo Control The Second Stereo Control is used to select the second stereo channel pair that can be encoded in an MPEG-2 stream instead of the multi-channel stereophonic information (3/2). If this Control is addressed on a decoder that does not implement Second Stereo support (D5 = ‘0’ in the bmMPEGCapabilities field of the MPEG format-specific descriptor), the control pipe must indicate a stall. The Second Stereo Control can have only the current setting attribute (CUR). The position of the 2ndStereoEnable switch can be either TRUE or FALSE. When FALSE, the main stereo channel pair is selected; when TRUE, the second stereo channel pair is selected. The current setting of the Control can be queried using a Get MPEG Control request. Table 2-11 Second Stereo Control Parameter Block Control Selector MP_SECOND_STEREO_CONTROL wLength 1 Offset Field Size Value Description 0 B2ndStereoEnable 1 Number The setting for the attribute of the Second Stereo Control. Main stereo channel pair selected when FALSE, second stereo channel pair selected when TRUE. 2.3.8.1.2.3.3 Multilingual Control The Multilingual Control is used to select the multilingual channel actually retrieved from the MPEG stream. If this Control is addressed on a decoder that does not implement multilingual support (D9..8 = USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 20 ‘00’ in the bmMPEGCapabilities field of the MPEG format-specific descriptor), the control pipe must indicate a stall. The Multilingual Control supports only the CUR Control attribute. The valid range is from zero (0x00) to seven (0x07). The actual range depends on the incoming MPEG stream. It may contain only a limited number of multilingual channels (less than seven). The Multilingual Control honors the request to the best of its abilities. It may truncate the attribute values to its closest available settings. It will report these settings when queried during a Get MPEG Control request. Table 2-12 Multilingual Control Parameter Block Control Selector MP_MULTILINGUAL_CONTROL wLength 1 Offset Field Size Value Description 0 bMultiLingual 1 Number The setting for the attribute of the multilingual channel selection 0 = decode no channel1..7 = decode channel 1..78..255 = reserved 2.3.8.1.2.3.4 Dynamic Range Control The Dynamic Range Control (DRC) is used to enable or disable the Dynamic Range Control functionality of the decoder. If the decoder does not support Dynamic Range control (D5..4 = ‘00’ in the bmMPEGFeaturesfield of the MPEG format-specific descriptor), the control pipe must indicate a stall when receiving this request. The Dynamic Range Control can have only the current setting attribute (CUR). The position of the DRC switch can be either TRUE or FALSE. TRUE means that the MPEG decoder is using the Dynamic Range control words (possibly with additional scaling) contained in the MPEG 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 MPEG Control request. Table 2-13 Dynamic Range Control Parameter Block Control Selector MP_DYN_RANGE_CONTROL wLength 1 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.1.2.3.5 Scaling Control The Scaling Control is used to manipulate the single scaling coefficient used by MPEG decoders that implement a common boost/cut scaling value for Dynamic Range Control (D5..4 = ‘10’ in the bmMPEGFeatures field of the MPEG format-specific descriptor). If this Control is addressed on a non- ‘10’ decoder, the control pipe must indicate a stall. 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/gr-digital/pages/15.html
GR DIGITAL III GR DIGITAL IIIコンパクト デジタルカメラリコー(Ricoh) GR DI... [3年保険付]RICOH GR DIGITAL III コンパクトデジカメ【即納】【あす楽対応_関東】【あす楽対応... 【送料無料】GR DIGITAL III 大口径レンズ「GR レンズ 28mm F1.9」/高感度タイプのCCDなどを搭... 関連記事 #blogsearch2
https://w.atwiki.jp/usb_audio/pages/21.html
原文：Audio Data Formats 1.0(PDF) USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 6 1 Introduction The intention of this document is to describe in detail all the Audio Data Formats that are supported by the Audio Device Class. This document is considered an integral part of the Audio Device Class Specification, although subsequent revisions of this document are independent of the revision evolution of the main USB Audio Specification. This is to easily accommodate the addition of new Audio Data Formats without impeding the core USB Audio Specification. 1.1 Related Documents · Universal Serial Bus Specification, 1.0 final draft revision (also referred to as the USB Specification). In particular, see Chapter 9, “USB Device Framework.” · Universal Serial Bus Device Class Definition for Audio Data Formats (referred to in this document as USB Audio Data Formats). · Universal Serial Bus Device Class Definition for Terminal Types (referred to in this document as USB Audio Terminal Types). · ANSI S1.11-1986 standard. · MPEG-1 standard ISO/IEC 111172-3 1993. · MPEG-2 standard ISO/IEC 13818-3 Feb. 20, 1997. · Digital Audio Compression Standard (AC-3), ATSC A/52 Dec. 20, 1995. (available from http //www.atsc.org) · ANSI/IEEE-754 floating-point standard. · ISO/IEC 958 International Standard Digital Audio Interface and Annexes. · ISO/IEC 1937 standard. · ITU G.711 standard. 1.2 Terms and Abbreviations This section defines terms used throughout this document. For additional terms that pertain to the Universal Serial Bus, see Chapter 2, “Terms and Abbreviations,” in the USB Specification. Audio Frame A collection of audio subframes, each containing a PCM audio sample of a different physical audio channel, taken at the same moment in time. Audio Stream A concatenation of a potentially very large number of audio frames ordered according to ascending time. Audio Subframe Holds a single PCM audio sample. DVD Acronym for Digital Versatile Disc. Encoded Audio Bitstream A concatenation of a potentially very large number of encoded audio frames, ordered according to ascending time. Encoded Audio Frame A sequence of bits that contains an encoded representation of one or more physical audio channels. MPEG Acronym for Moving Pictures Expert Group. PCM Acronym for Pulse Coded Modulation. Transfer Delimiter A unique token that indicates an interruption in an isochronous data packet stream. Can be either a zerolength data packet or the absence of an isochronous transfer in a certain USB frame. USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 7 blank page USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 8 2 Audio Data Formats Audio Data Formats can be divided in three main groups according to type. The first group, Type I, deals with audio data streams that are constructed on a sample-by-sample basis. Each audio sample is represented by a single independent symbol and the data stream is built up by concatenating those symbols. Different compression schemes may be used to transform the audio samples into symbols. If multiple physical audio channels are formatted into a single audio channel cluster, then samples at time x of subsequent channels are transmitted interleaved, according to the cluster channel ordering as described in the main USB Audio Specification, followed by samples at time x+1, interleaved in the same fashion and so on. The notion of physical channels is explicitly preserved during transmission. A typical example of Type I formats is the standard PCM audio data. The second group, Type II, deals with those formats that do not preserve the notion of physical channels during the transmission. Typically, all non-PCM encoded audio data streams belong to this group. A number of audio samples, often originating from multiple physical channels, are encoded into a number of bits in such a way that, after transmission, the original audio samples can be reconstructed to a certain degree of accuracy. The number of bits used for transmission is typically one or more orders of magnitude smaller than the number of bits needed to represent the original PCM audio samples, effectively realizing a considerable bandwidth reduction during transmission. The third group, Type III, contains special formats that do not fit in both previous groups. In fact, they mix characteristics of Type I and Type II groups to transmit audio data streams. One or more non-PCM encoded audio data streams are packed into “pseudo-stereo samples” and transmitted as if they were real stereo PCM audio samples. The sampling frequency of these pseudo samples matches the sampling frequency of the original PCM audio data streams. Therefore, clock recovery at the receiving end is easier than it is in the case of Type II formats. The drawback is that unless multiple non-PCM encoded streams are packed into one pseudo stereo stream, more bandwidth than necessary is consumed. Section A.1, “Audio Data Format Codes” summarizes the Audio Data Formats that are currently supported in the Audio Device Class. The following sections explain those formats in more detail. 2.1 Transfer Delimiter Isochronous data streams are continuous in nature, although the actual number of bytes sent per packet may vary throughout the lifetime of the stream (for rate adaptation purposes for instance). To indicate a temporary stop in the isochronous data stream without closing the pipe (and thus relinquishing the USB bandwidth), an in-band Transfer Delimiter needs to be defined. This specification considers two situations to be a Transfer Delimiter. The first is a zero-length data packet and the second is the absence of an isochronous transfer in a particular USB frame. Both situations are considered equivalent and the audio function is expected to behave the same. However, the second type consumes less isochronous USB bandwidth (i.e. zero bandwidth). In both cases, this specification considers a Transfer Delimiter to be an entity that can be sent over the USB. 2.2 Type I Formats The following sections describe the Audio Data Formats that belong to Type I. A number of terms and their definition are presented. 2.2.1 USB Packets Audio data streams that are inherently continuous must be packetized when sent over the USB. The quality of the packetizing algorithm directly influences the amount of effort needed to reconstruct a reliable sample clock at the receiving side. The goal must be to keep the instantaneous number of samples USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 9 per frame (ni) as close as possible to the average number of samples per frame, (nav). The average nav should be calculated as a sliding average over a period of 256 frames. If the sampling rate is a constant, the allowable variation on ni is limited to one sample, that is, Dni = 1. This implies that all packets must either contain INT (nav ) (small packet) or INT (nav ) + 1 (large packet) samples. For all i ni = INT (nav) | INT (nav) + 1 Note In the case where nav = INT (nav ), ni may vary between INT (nav) - 1 (small packet), INT (nav) (medium packet) and INT (nav) + 1 (large packet). To limit the needed buffer depths to acceptable limits, this specification limits the cumulative difference between nav and ni to ±1.5 samples. If the sampling rate can be varied (to implement pitch control), the allowable pitch shift is 1kHz/ms. That is, the allowable variation on ni is limited to one sample per frame. For all i ni+1 = ni ± 1 Pitch control is restricted to adaptive endpoints only. AudioStreaming interfaces that support pitch control on their isochronous endpoint are required to report this in the class-specific endpoint descriptor. In addition, a Set/Get Pitch Control request is required to enable or disable the pitch control functionality. 2.2.2 Audio Subframe The basic structure used to represent audio data is the audio subframe. An audio subframe holds a single audio sample. An audio subframe always contains an integer number of bytes. This specification limits the possible audio subframe sizes (bSubframeSize) to 1, 2, 3 or 4 bytes per audio subframe. An audio sample is represented using a number of bits (bBitResolution) less than or equal to the total number of bits available in the audio subframe, i.e. bBitResolution £ bSubframeSize*8. AudioStreaming endpoints must be constructed in such a way that a valid transfer can take place as long as the reported audio subframe size (bSubframeSize) is respected during transmission. If the reported bits per sample (bBitResolution) do not correspond with the number of significant bits actually used during transfer, the device will either discard trailing significant bits ([actual_bits_per_sample] bBitResolution) or interpret trailing zeros as significant bits ([actual_bits_per_sample] bBitResolution). 2.2.3 Audio Frame An audio frame consists of a collection of audio subframes, each containing an audio sample of a different physical audio channel, taken at the same moment in time. The number of audio subframes in an audio frame equals the number of logical audio channels in the audio channel cluster. The ordering of the audio subframes in the audio frame obeys the rules set forth in the USB Audio Specification. All audio subframes must have the same audio subframe size. 2.2.4 Audio Streams An audio stream is a concatenation of a potentially very large number of audio frames, ordered according to ascending time. Streams are packetized when transported over USB whereby USB packets can only contain an integer number of audio frames. Each packet always starts with the same channel, and the channel order is respected throughout the entire transmission. If, for any reason, there are no audio frames available to construct a USB packet, a Transfer Delimiter must be sent instead. USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 10 2.2.5 Type I Format Type Descriptor The Type I format type descriptor starts with the usual three fields bLength, bDescriptorType, and bDescriptorSubtype. The bFormatType field indicates this is a Type I descriptor. The bNrChannels field contains the number of physical channels in the audio data stream. The bSubframeSize field indicates how many bytes are used to transport an audio subframe. The bBitResolution field indicates how many bits of the total number of available bits in the audio subframe are truly used by the audio function to convey audio information. The sampling frequency capabilities of the isochronous data endpoint of the AudioStreaming Interface are reported as well. Depending on the bSamFreqType field, the length of the descriptor varies and the interpretation of the trailing fields differs. Sampling frequencies occupy three bytes and are expressed in Hz to support over-sampled, reduced bit-resolution systems (the range is from 0 to 16,777,215 Hz). Table 2-1 Type I Format Type Descriptor Offset Field Size Value Descriptio 0 bLength 1 Number Size of this descriptor, in bytes 8+(ns*3) 1 bDescriptorType 1 Constant CS_INTERFACE descriptor type. 2 bDescriptorSubtype 1 Constant FORMAT_TYPE descriptor subtype. 3 bFormatType 1 Constant FORMAT_TYPE_I. Constant identifying the Format Type the AudioStreaming interface is using. 4 bNrChannels 1 Number Indicates the number of physical channels in the audio data stream. 5 bSubframeSize 1 Number The number of bytes occupied by one audio subframe. Can be 1, 2, 3 or 4. 6 bBitResolution 1 Number The number of effectively used bits from the available bits in an audio subframe. 7 bSamFreqType 1 Number Indicates how the sampling frequency can be programmed 0 Continuous sampling frequency1..255 The number of discrete sampling frequencies supported by the isochronous data endpoint of the AudioStreaming interface (ns) 8... See sampling frequency tables, below. Depending on the value in the bSamFreqType field, the layout of the next part of the descriptor is as shown in the following tables. Table 2-2 Continuous Sampling Frequency Offset Field Size Value Descriptio 1 - 6 - 11 - 16 - 21 - 26 - 31 ここを編集
https://w.atwiki.jp/usb_audio/pages/31.html
原文：Audio Device Document 1.0(PDF) USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 16 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. USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 17 2 Management Overview The USB is very well suited for transport of audio (voice and sound). PC-based voice telephony is one of the major drivers of USB technology. In addition, the USB has more than enough bandwidth for sound, even high-quality audio. Many applications related to voice telephony, audio playback, and recording can take advantage of the USB. In principle, a versatile bus specification like the USB provides many ways to propagate and 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 USB. However, provisions have been made so that vendor-specific audio formats and compression schemes can be handled. USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 18 3 Functional Characteristics 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 CD-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. Audio functions are addressed through their audio interfaces. Each audio function has a single AudioControl interface and can have several AudioStreaming and 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 are 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. Note All MIDI-related information is grouped in a separate document, Universal Serial Bus Device Class Definition for MIDIStreaming Interfacesthat is considered part of this specification. 3.1 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 through USB belong to this class. In fact, for an audio function to be part of this class, the only requirement is that it exposes one AudioControl interface. No further interaction with the function is mandatory, although most functions in the audio interface class will support one or more optional AudioStreaming interfaces for consuming or producing one or more isochronous audio data streams. The Audio Interface class code is assigned by the USB. For details, see Section A.1, “Audio Interface Class Code.” 3.2 Audio Interface Subclass and Protocol The Audio Interface class is divided into Subclasses that can be further qualified by the Interface Protocol code. However, at this moment, the Interface Protocol is not used and must be set to 0x00. All audio functions are part of a certain Subclass. The following three Subclasses are currently defined in this specification · AudioControl Interface Subclass · AudioStreaming Interface Subclass · MIDIStreaming Interface Subclass The assigned codes can be found in Sections A.2, “Audio Interface Subclass Codes” and A.3, “Audio Interface Protocol Codes” of this specification. All other Subclass codes are unused and reserved except code 0xFF which is by specification reserved for vendor-specific extensions. USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 19 3.3 Audio Synchronization Types Each isochronous audio endpoint used in an AudioStreaming interface belongs to a synchronization type as defined in Section 5 of the USB Specification. The following sections briefly describe the possible synchronization types. 3.3.1 Asynchronous Asynchronous isochronous audio endpoints produce or consume data at a rate that is locked either to a clock external to the USB or to a free-running internal clock. These endpoints cannot be synchronized to a start of frame (SOF) or to any other clock in the USB domain. 3.3.2 Synchronous The clock system of synchronous isochronous audio endpoints can be controlled externally through SOF synchronization. Such an endpoint must do one of the following · Slave its sample clock to the 1ms SOF tick. · Control the rate of USB SOF generation so that its data rate becomes automatically locked to SOF. 3.3.3 Adaptive Adaptive isochronous audio endpoints are able to source or sink data at any rate within their operating range. This implies that these endpoints must run an internal process that allows them to match their natural data rate to the data rate that is imposed at their interface. 3.4 Inter Channel Synchronization An important issue when dealing with audio, and 3-D audio in particular, is the phase relationship between different physical audio channels. Indeed, the virtual spatial position of an audio source is directly related to and influenced by the phase differences that are applied to the different physical audio channels used to reproduce the audio source. Therefore, it is imperative that USB audio functions respect the phase relationship among all related audio channels. However, the responsibility for maintaining the phase relation is shared among the USB host software, hardware, and all of the audio peripheral devices or functions. To provide a manageable phase model to the host, an audio function is required to report its internal delay for every AudioStreaming interface. This delay is expressed in number of frames (ms) and is due to the fact that the audio function must buffer at least one frame worth of samples to effectively remove packet jitter within a frame. Furthermore, some audio functions will introduce extra delay because they need time to correctly interpret and process the audio data streams (for example, compression and decompression). However, it is required that an audio function introduces only an integer number of frames of delay. In the case of an audio source function, this implies that the audio function must guarantee that the first sample it fully acquires after SOFn (start of frame n) is the first sample of the packet it sends over USB during frame (n+d). d is the audio function’s internal delay expressed in ms. The same rule applies for an audio sink function. The first sample in the packet, received over USB during frame n, must be the first sample that is fully reproduced during frame (n+d). By following these rules, phase jitter is limited to ±1 audio sample. It is up to the host software to synchronize the different audio streams by scheduling the correct packets at the correct moment, taking into account the internal delays of all audio functions involved. USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 20 3.5 Audio Function Topology To be able to manipulate the physical properties of an audio function, its functionality must be divided into addressable Entities. Two types of such generic Entities are identified and are called Units and Terminals. Units provide the basic building blocks to fully describe most audio functions. Audio functions are built by connecting together several of these Units. A Unit has one or more Input Pins and a single Output Pin, where each Pin represents a cluster of logical audio channels inside the audio function. Units are wired together by connecting their I/O Pins according to the required topology. In addition, the concept of a Terminal is introduced. There are two types of Terminals. An Input Terminal (IT) is an Entity that represents a starting point for audio channels inside the audio function. An Output Terminal (OT) represents an ending point for audio channels. From the audio function’s perspective, a USB endpoint is a typical example of an Input or Output Terminal. It either provides data streams to the audio function (IT) or consumes data streams coming from the audio function (OT). Likewise, a Digital to Analog converter, built into the audio function is represented as an Output Terminal in the audio function’s model. Connection to the Terminal is made through its single Input or Output Pin. Input Pins of a Unit are numbered starting from one up to the total number of Input Pins on the Unit. The Output Pin number is always one. Terminals only have one Input or Output Pin that is always numbered one. The information, traveling over I/O Pins is not necessarily of a digital nature. It is perfectly possible to use the Unit model to describe fully analog or even hybrid audio functions. The mere fact that I/O Pins are connected together is a guarantee (by construction) that the protocol and format, used over these connections (analog or digital), is compatible on both ends. Every Unit in the audio function is fully described by its associated Unit Descriptor (UD). The Unit Descriptor contains all necessary fields to identify and describe the Unit. Likewise, there is a Terminal Descriptor (TD) for every Terminal in the audio function. In addition, these descriptors provide all necessary information about the topology of the audio function. They fully describe how Terminals and Units are interconnected. This specification describes the following seven different types of standard Units and Terminals that are considered adequate to represent most audio functions available today and in the near future · Input Terminal · Output Terminal · Mixer Unit · Selector Unit · Feature Unit · Processing Unit · Extension Unit The ensemble of UDs and TDs provide a full description of the audio function to the Host. A generic audio driver should be able to fully control the audio function, except for the functionality, represented by Extension Units. Those require vendor-specific extensions to the audio class driver. The descriptors are further detailed in Section 4, “Descriptors” of this document. Inside a Unit, functionality is further described through audio Controls. A Control typically provides access to a specific audio property. Each Control has a set of attributes that can be manipulated or that present additional information on the behavior of the Control. A Control can have the following four attributes · Current setting attribute · Minimum setting attribute · Maximum setting attribute 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/digital111/pages/21.html
デバイス
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/61.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 6 Table of Contents Scope of This Release.............................................................................................................2 Contributors............................................................................................................................2 Revision History.......................................................................................................................2 Table of Contents.....................................................................................................................6 List of Tables...........................................................................................................................7 List of Figures.........................................................................................................................8 List of Figures.........................................................................................................................8 1 Introduction......................................................................................................................9 1.1 Related Documents.....................................................................................................9 1.2 Terms and Abbreviations.............................................................................................9 2 Audio Data Formats........................................................................................................11 2.1 Transfer Delimiter......................................................................................................12 2.2 Virtual Frame and Virtual Frame Packet Definitions.................................................13 2.3 Simple Audio Data Formats.......................................................................................13 2.3.1 Type I Formats...................................................................................................13 2.3.2 Type II Formats..................................................................................................17 2.3.3 Type III Formats.................................................................................................19 2.3.4 Type IV Formats.................................................................................................20 2.4 Extended Audio Data Formats..................................................................................21 2.4.1 Extended Type I Formats...................................................................................21 2.4.2 Extended Type II Formats..................................................................................23 2.4.3 Extended Type III Formats.................................................................................24 2.4.4 Side Band Protocols...........................................................................................25 3 Adding New Audio Data Formats..................................................................................27 4 Adding New Side Band Protocols.................................................................................28 Appendix A. Additional Audio Device Class Codes....................................................29 A.1 Format Type Codes...................................................................................................29 A.2 Audio Data Format Bit Allocation in the bmFormats field..........................................29 A.2.1 Audio Data Format Type I Bit Allocations..........................................................29 A.2.2 Audio Data Format Type II Bit Allocations.........................................................29 A.2.3 Audio Data Format Type III Bit Allocations........................................................30 A.2.4 Audio Data Format Type IV Bit Allocations........................................................30 A.3 Side Band Protocol Codes........................................................................................31 Release 2.0 May 31, 2006 6 Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 7 List of Tables Table 2-1 Packetization........................................................................................................14 Table 2-2 Type I Format Type Descriptor...........................................................................15 Table 2-3 Type II Format Type Descriptor..........................................................................18 Table 2-4 Type III Format Type Descriptor.........................................................................20 Table 2-5 Type IV Format Type Descriptor.........................................................................21 Table 2-6 Extended Type I Format Type Descriptor..........................................................22 Table 2-7 Extended Type II Format Type Descriptor.........................................................23 Table 2-8 Extended Type III Format Type Descriptor........................................................25 Table 2-9 Hi-Res Presentation TimeStamp Layout............................................................25 Table A-1 Format Type Codes.............................................................................................29 Table A-2 Audio Data Format Type I Bit Allocations.........................................................29 Table A-3 Audio Data Format Type II Bit Allocations........................................................29 Table A-4 Audio Data Format Type III Bit Allocations.......................................................30 Table A-5 Audio Data Format Type IV Bit Allocations......................................................30 Table A-6 Side Band Protocol Codes.................................................................................31 Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 8 List of Figures Figure 2-1 Type I Audio Stream...........................................................................................11 Figure 2-2 Type II Audio Stream..........................................................................................12 Figure 2-3 Extended Type I Format.....................................................................................22 Figure 2-4 Extended Type II Format....................................................................................23 Figure 2-5 Extended Type III Format...................................................................................24 Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 9 1 Introduction The intention of this document is to describe in detail all the Audio Data Formats that are supported by the Audio Device Class. This document is considered an integral part of the Audio Device Class Specification, although subsequent revisions of this document are independent of the revision evolution of the main USB Audio Specification. This is to easily accommodate the addition of new Audio Data Formats without impeding the core USB Audio Specification. 1.1 Related Documents • Universal Serial Bus Specification, 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 Devices (referred to in this document as USB Audio Device Class). • 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. (available from http //www.iso.ch ) • MPEG-2 standard ISO/IEC 13818-3 Feb. 20, 1997. (available from http //www.iso.ch ) • Digital Audio Compression Standard (AC-3), ATSC A/52A Aug. 20, 2001. (available from http //www.atsc.org ) • Windows Media Audio (WMA) specification. (available from http //www.microsoft.com) • ANSI/IEEE-754 floating-point standard. • ISO/IEC 60958 International Standard Digital Audio Interface and Annexes. • ISO/IEC 61937 standard. • ITU G.711 standard. • ETSI Specification TS 102 114, “DTS Coherent Acoustics; Core and Extensions”. (Available from http //webapp.etsi.org/action%5CPU/20020827/ts_102114v010101p.pdf) 1.2 Terms and Abbreviations This section defines terms used throughout this document. For additional terms that pertain to the Universal Serial Bus, see Chapter 2, “Terms and Abbreviations,” in the USB Specification. AC-3 Audio compression standard from Dolby Labs. Audio Slot A collection of audio subslots, each containing a PCM audio sample of a different physical audio channel, taken at the same moment in time. Audio Stream A concatenation of a potentially very large number of audio slots ordered according to ascending time. Audio Subslot Holds a single PCM audio sample. DTS Acronym for Digital Theater Systems. DVD Acronym for Digital Versatile Disc. Encoded Audio Bit Stream A concatenation of a potentially very large number of encoded audio frames, ordered according to ascending time. Encoded Audio Frame A sequence of bits that contains an encoded representation of audio samples from one or more physical audio channels taken over a fixed period of time. Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 10 MPEG Acronym for Moving Pictures Expert Group. PCM Acronym for Pulse Coded Modulation. Virtual Frame A grouping of USB (micro)frames that are related. Virtual Frame Packet A packet that contains all the audio slots that are transferred over the bus during a virtual frame. Transfer Delimiter A unique token that indicates an interruption in an isochronous data packet stream. Can be either a zero-length data packet or the absence of an isochronous transfer in a certain USB frame. WMA Acronym for Windows Media Audio. 1 - 6 - 11 - 16 - 21 - 26 - 31 ここを編集
https://w.atwiki.jp/usb_audio/pages/49.html
原文：Audio Device Document 1.0(PDF) USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 101 wProcessType Value CHORUS_PROCESS 0x05 DYN_RANGE_COMP_PROCESS 0x06 A.8 Audio Class-Specific Endpoint Descriptor Subtypes Table A-8 Audio Class-Specific Endpoint Descriptor Subtypes Descriptor Subtype Value DESCRIPTOR_UNDEFINED 0x00 EP_GENERAL 0x01 A.9 Audio Class-Specific Request Codes Table A-9 Audio Class-Specific Request Codes Class-Specific Request Code Value REQUEST_CODE_UNDEFINED 0x00 SET_ CUR 0x01 GET_ CUR 0x81 SET_ MIN 0x02 GET_ MIN 0x82 SET_ MAX 0x03 GET_ MAX 0x83 SET_ RES 0x04 GET_ RES 0x84 SET_MEM 0x05 GET_ MEM 0x85 GET_STAT 0xFF USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 102 A.10 Control Selector Codes A.10.1 Terminal Control Selectors Table A-10 Terminal Control Selectors Control Selector Value TE_CONTROL_UNDEFINED 0x00 COPY_PROTECT_CONTROL 0x01 A.10.2 Feature Unit Control Selectors Table A-11 Feature Unit Control Selectors Control Selector Value FU_CONTROL_UNDEFINED 0x00 MUTE_CONTROL 0x01 VOLUME_CONTROL 0x02 BASS_CONTROL 0x03 MID_CONTROL 0x04 TREBLE_CONTROL 0x05 GRAPHIC_EQUALIZER_CONTROL 0x06 AUTOMATIC_GAIN_CONTROL 0x07 DELAY_CONTROL 0x08 BASS_BOOST_CONTROL 0x09 LOUDNESS_CONTROL 0x0A A.10.3 Processing Unit Control Selectors A.10.3.1 Up/Down-mix Processing Unit Control Selectors Table A-12 Up/Down-mix Processing Unit Control Selectors Control Selector Value UD_CONTROL_UNDEFINED 0x00 UD_ENABLE_CONTROL 0x01 UD_MODE_SELECT_CONTROL 0x02 USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 103 A.10.3.2 Dolby PrologicÔ Processing Unit Control Selectors Table A-13 Dolby Prologic Processing Unit Control Selectors Control Selector Value DP_CONTROL_UNDEFINED 0x00 DP_ENABLE_CONTROL 0x01 DP_MODE_SELECT_CONTROL 0x02 A.10.3.3 3D Stereo Extender Processing Unit Control Selectors Table A-14 3D Stereo Extender Processing Unit Control Selectors Control Selector Value 3D_CONTROL_UNDEFINED 0x00 3D_ENABLE_CONTROL 0x01 SPACIOUSNESS_CONTROL 0x03 A.10.3.4 Reverberation Processing Unit Control Selectors Table A-15 Reverberation Processing Unit Control Selectors Control Selector Value RV_CONTROL_UNDEFINED 0x00 RV_ENABLE_CONTROL 0x01 REVERB_LEVEL_CONTROL 0x02 REVERB_TIME_CONTROL 0x03 REVERB_FEEDBACK_CONTROL 0x04 A.10.3.5 Chorus Processing Unit Control Selectors Table A-16 Chorus Processing Unit Control Selectors Control Selector Value CH_CONTROL_UNDEFINED 0x00 CH_ENABLE_CONTROL 0x01 CHORUS_LEVEL_CONTROL 0x02 CHORUS_RATE_CONTROL 0x03 USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 104 Control Selector Value CHORUS_DEPTH_CONTROL 0x04 A.10.3.6 Dynamic Range Compressor Processing Unit Control Selectors Table A-17 Dynamic Range Compressor Processing Unit Control Selectors Control Selector Value DR_CONTROL_UNDEFINED 0x00 DR_ENABLE_CONTROL 0x01 COMPRESSION_RATE_CONTROL 0x02 MAXAMPL_CONTROL 0x03 THRESHOLD_CONTROL 0x04 ATTACK_TIME 0x05 RELEASE_TIME 0x06 A.10.4 Extension Unit Control Selectors Table A-18 Extension Unit Control Selectors Control Selector Value XU_CONTROL_UNDEFINED 0x00 XU_ENABLE_CONTROL 0x01 A.10.5 Endpoint Control Selectors Table A-19 Endpoint Control Selectors Control Selector Value EP_CONTROL_UNDEFINED 0x00 SAMPLING_FREQ_CONTROL 0x01 PITCH_CONTROL 0x02 USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 105 Appendix B. Example 1 USB Microphone (Informative) B.1 Product Description The device described here is a USB Microphone. It is a very simple device that has no Audio Controls incorporated. It delivers a mono audio data stream to the Host over its AudioStreaming interface. The used Audio Data Format is 16-bit 8KHz PCM. The synchronization type is Asynchronous Source. It uses its internal clock as a reference. The following figure presents the internal topology of the microphone. AudioStreaming Interface AudioControl Interface Audio Function Desktop Microphone IT OT USB IN Endpoint Figure B-1 USB Microphone Topology The audio function contains one Input Terminal that represents the actual microphone pick-up element, followed by the Analog-to-Digital Converter (ADC). The digital output stream of the ADC enters the audio function through the single Output Pin of the Input Terminal. Because there is no further processing on the audio stream, the Input Terminal is directly connected to the Input Pin of the Output Terminal. The Output Terminal is the representation within the audio function of the USB IN endpoint that eventually delivers the audio data stream to the Host. The internals of the audio function are presented to the Host through the (mandatory) AudioControl interface whereas the USB IN endpoint resides in the AudioStreaming interface. B.2 Descriptor Hierarchy This USB Microphone device includes the AudioControl interface (interface 0) and a single AudioStreaming interface (interface 1). The AudioStreaming interface features two alternate settings. The first alternate setting (Alternate Setting 0) has zero bandwidth associated with it so that switching to this alternate setting effectively frees all allocated bandwidth on the USB for this device. Zero bandwidth is indicated by the lack of a streaming endpoint. Alternate Setting 1 is the operational part of the interface and it has one isochronous IN endpoint. Figure presents the descriptor hierarchy. 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 ここを編集