Universal Serial Bus Device Class Definition for Audio Data Formats
Release 2.0 May 31, 2006 21
Setting and encoded data streams (IEC61937) in another Alternate Setting of the interface. Note however that the external connection could also be vendor specific (like a parallel data interface).
2.3.4.1 Type IV Format Type Descriptor
The bFormatType field indicates this is a Type IV descriptor.
Table 2-5: Type IV Format Type Descriptor
| Offset |
Field |
Size |
Value |
Description |
| 0 |
bLength |
1 |
Number |
Size of this descriptor, in bytes: 4 |
| 1 |
bDescriptorType |
1 |
Constant |
CS_INTERFACE descriptor type. |
| 2 |
bDescriptorSubtype |
1 |
Constant |
FORMAT_TYPE descriptor subtype. |
| 3 |
bFormatType |
1 |
Constant |
FORMAT_TYPE_IV. Constant identifying the Format Type the AudioStreaming interface is using. |
2.3.4.2 Type IV Supported Formats
This specification supports all Audio Data Formats on an external connection that are defined on a USB pipe (Type I, II, and III). See Section 2.3.1.7, “Type I Supported Formats”, Section 2.3.2.8, “Type II Supported Formats”, and Section 2.3.3.2, “Type III Supported Formats”.
The bit allocations in the bmFormats field of the class-specific AS interface descriptor for the different Type IV Audio Data Formats can be found in Appendix A.2.4, “Audio Data Format Type IV Bit Allocations.”
2.4 Extended Audio Data Formats
Extended Audio Data Formats add support for a Packet Header to the previously defined Simple Audio Data Formats Type I, II, and III. For the Extended Audio Data Format Type I, an additional optional synchronous Control Channel is defined.
2.4.1 Extended Type I Formats
Extended Audio Data Format Type I adds support for both a Packet Header and a synchronous Control Channel to the Simple Type I Format definition.
All three elements (Packet Header, audio data, and Control Channel) of an Extended Type I packet are optional. The Extended Format Type I descriptor (see further) indicates which elements are present. It is therefore possible to provide only a Control Channel, without Packet Header or audio data. The following figure further illustrates the concept.
Universal Serial Bus Device Class Definition for Audio Data Formats
Release 2.0 May 31, 2006 22
Figure 2-3: Extended Type I Format
Each Virtual Frame Packet (VFP) can start with an optional Packet Header. If Packet Headers are used, they must be present in every VFP. The length of the Packet Header must be the same for every VFP. The Packet Header is then followed by a number of Extended Audio Slots. An Extended Audio Slot is the concatenation of a Control Word, followed by the Type I Audio Slot. The Control Channel therefore consists of a stream of Control Words, where each Control Word is synchronous to its associated Audio Slot. There are as many Control Channel Words per VFP as there are Audio Slots in the VFP. The byte size of the Control Words is independent of the Audio Subslot size and is the same for each Audio Slot.
2.4.1.1 Extended Type I Format Type Descriptor
The first part of the Extended Type I Format Type descriptor is identical to the Simple Type I Format Type descriptor (See Section 2.3.1.6, “Type I Format Type Descriptor”.) Three additional fields are added to describe the Packet Header and the Control Channel.
The bHeaderLength field indicates the number of bytes contained in the Packet Header. The bControlSize field indicates the size in bytes of each Control Channel Word in the stream. The bSideBandProtocol field contains a constant identifying the Side Band Protocol that is used for the Packet Header and Control Channel. This specification defines a number of Side Band Protocols (See Section 2.4.4, “Side Band Protocols”).
If the Packet Header is not used, then the bHeaderLength field must be set to 0. Likewise, if the Control Channel is not implemented, then the bControlSize field must be set to 0. If the stream does not contain actual audio data, the bNrChannels, bmChannelConfig and iChannelNames in the class-specific AS Interface descriptor (See the USB Audio Device Class document) must all be set to 0.
Table 2-6: Extended Type I Format Type 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_TYPE descriptor subtype. |
| 3 |
bFormatType |
1 |
Constant |
EXT_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. |
Universal Serial Bus Device Class Definition for Audio Data Formats
Release 2.0 May 31, 2006 23
| Offset |
Field |
Size |
Value |
Description |
| 5 |
bBitResolution |
1 |
Number |
The number of effectively used bits from the available bits in an audio subslot. |
| 6 |
bHeaderLength |
1 |
Number |
Size of the Packet Header, in bytes. |
| 7 |
bControlSize |
1 |
Number |
Size of the Control Channel Words, in bytes. |
| 8 |
bSideBandProtocol |
1 |
Constant |
Constant, identifying the Side Band Protocol used for the Packet Header and Control Channel content. |
2.4.2 Extended Type II Formats
Extended Audio Data Format Type II adds support for a Packet Header to the Simple Type II Format definition.
The elements (Packet Header and audio data) of an Extended Type II packet are optional. The Extended Format Type II descriptor (see further) indicates which elements are present. It is therefore possible to provide only a Packet Header without audio data. The following figure further illustrates the concept.
Figure 2-4: Extended Type II Format
Each Virtual Frame Packet (VFP) can start with an optional Packet Header. If Packet Headers are used, they must be present in every VFP. The length of the Packet Header must be the same for every VFP. The Packet Header is then followed by the actual encoded audio frame data.
2.4.2.1 Extended Type II Format Type Descriptor
The first part of the Extended Type II Format Type descriptor is identical to the Simple Type II Format Type descriptor (See Section 2.3.2.6, “Type II Format Type Descriptor”.) Two additional fields are added to describe the Packet Header.
The bHeaderLength field indicates the number of bytes contained in the Packet Header. The bSideBandProtocol field contains a constant identifying the Side Band Protocol that is used for the Packet Header. This specification defines a number of Side Band Protocols (See Section 2.4.4, “Side Band Protocols”).
If the Packet Header is not used, then the bHeaderLength field must be set to 0. If the stream does not contain actual audio data, the bNrChannels, bmChannelConfig and iChannelNames in the class-specific AS Interface descriptor (See the USB Audio Device Class document) must all be set to 0.
Table 2-7: Extended Type II Format Type Descriptor
| Offset |
Field |
Size |
Value |
Description |
| 0 |
bLength |
1 |
Number |
Size of this descriptor, in bytes: 10 |
Universal Serial Bus Device Class Definition for Audio Data Formats
Release 2.0 May 31, 2006 24
| Offset |
Field |
Size |
Value |
Description |
| 1 |
bDescriptorType |
1 |
Constant |
CS_INTERFACE descriptor type. |
| 2 |
bDescriptorSubtype |
1 |
Constant |
FORMAT_TYPE descriptor subtype. |
| 3 |
bFormatType |
1 |
Constant |
Ext_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 |
bHeaderLength |
1 |
Number |
Size of the Packet Header, in bytes. |
| 9 |
bSideBandProtocol |
1 |
Constant |
Constant, identifying the Side Band Protocol used for the Packet Header content. |
2.4.3 Extended Type III Formats
Extended Audio Data Format Type III adds support for a Packet Header to the Simple Type III Format definition.
The elements (Packet Header and audio data) of an Extended Type III packet are optional. The Extended Format Type III descriptor (see further) indicates which elements are present. It is therefore possible to provide only a Packet Header without audio data. The following figure further illustrates the concept.
Figure 2-5: Extended Type III Format
Each Virtual Frame Packet (VFP) can start with an optional Packet Header. If Packet Headers are used, they must be present in every VFP. The length of the Packet Header must be the same for every VFP. The Packet Header is then followed by the actual encoded audio frame data.
2.4.3.1 Extended Type III Format Type Descriptor
The first part of the Extended Type III Format Type descriptor is identical to the Simple Type III Format Type descriptor (See Section 2.3.3.1, “Type III Format Type Descriptor”.) Two additional fields are added to describe the Packet Header.
The bHeaderLength field indicates the number of bytes contained in the Packet Header. The bSideBandProtocol field contains a constant identifying the Side Band Protocol that is used for the Packet Header. This specification defines a number of Side Band Protocols (See Section 2.4.4, “Side Band Protocols”).
Universal Serial Bus Device Class Definition for Audio Data Formats
Release 2.0 May 31, 2006 25
If the Packet Header is not used, then the bHeaderLength field must be set to 0. If the stream does not contain actual audio data, the bNrChannels, bmChannelConfig and iChannelNames in the class-specific AS Interface descriptor (See the USB Audio Device Class document) must all be set to 0.
Table 2-8: Extended Type III Format Type Descriptor
| Offset |
Field |
Size |
Value |
Description |
| 0 |
bLength |
1 |
Number |
Size of this descriptor, in bytes: 8 |
| 1 |
bDescriptorType |
1 |
Constant |
CS_INTERFACE descriptor type. |
| 2 |
bDescriptorSubtype |
1 |
Constant |
FORMAT_TYPE descriptor subtype. |
| 3 |
bFormatType |
1 |
Constant |
EXT_FORMAT_TYPE_III. Constant identifying the Format Type the AudioStreaming interface is using. |
| 4 |
bSubslotSize |
1 |
Number |
The number of bytes occupied by one audio subslot. Must be set to two. |
| 5 |
bBitResolution |
1 |
Number |
The number of effectively used bits from the available bits in an audio subslot. |
| 6 |
bHeaderLength |
1 |
Number |
Size of the Packet Header, in bytes. |
| 7 |
bSideBandProtocol |
1 |
Constant |
Constant, identifying the Side Band Protocol used for the Packet Header content. |
2.4.4 Side Band Protocols
This specification currently defines a single Side Band Protocol. Additional Protocols can be added later if needed.
2.4.4.1 Presentation Timestamp Side Band Protocol
The Presentation Timestamp protocol only uses the Packet Header to convey high resolution time information over the isochronous pipe. The Packet header is 12 bytes in size. It must occur at the start of each VFP.
Bit D0 in the bmFlags field indicates whether this is a valid timestamp (D0 = 0b1) or a repeated or non-valid timestamp (D0 = 0b0). When D0 is set to zero, the time fields of the Packet Header must be ignored.
The qNanoSeconds field indicates the time T at which the first sample in the VFP needs to be rendered with respect to the start of the stream (T = 0). The qNanoSeconds field can range from 0 to 263-1 ns (Bit 63 is considered to be a sign bit and must be set to zero). It is up to the entity that generates the timestamp to decide to which accuracy the timestamp will be rendered.
Table 2-9: Hi-Res Presentation TimeStamp Layout
| Offset |
Field |
Size |
Value |
Description |
| 0 |
bmFlags |
4 |
Bitmap |
D30..0: Reserved. Must be set to 0.
D31: Valid. |
最終更新：2011年06月04日 19:06
