throbber
Universal Serial Bus
`Device Class Definition
`for
`Audio Data Formats
`
`Release 1.0
`
`March 18, 1998
`
`Petitioners
`Exhibit 1011, Page 1
`
`

`
`Scope of This Release
`
`Contributors
`
`Revision History
`
`Gal AshourIBM CorporationBilly BrackenridgeMicrosoft CorporationOren TiroshAltec LansingCraig ToddDolby LaboratoriesRemy ZimmermannLogitechGeert KnapenPhilips ITCLInterleuvenlaan 74-76B-3001 Leuven-Heverlee BELGIUMPhone: +32 16 390 734Fax: +32 16 390 600E-mail: Geert.Knapen@innet.be
`0.1Dec. 1, 96Frmts01.docGeert KnapenInitial version0.2Jan. 1, 97Frmts02.docGeert KnapenCorrected typos.0.3Mar. 1, 97Frmts03.docGeert KnapenAdapted template and contents tocorrespond with core document.0.9rcApr. 1, 97Frmts09rc.docGeert KnapenBrought in line with core document. AddedType II descriptors and requests.0.9May 1, 97Frmts09.docGeert KnapenAdded details for MPEG and AC-3. Addedformat-specific requests.0.9CESep 1, 97Frmts09CE.docGeert KnapenCopy-edited for publication on the web.0.9aOct 1, 97Frmts09a.docGeert KnapenIncorporated RRs1.0RCMar 1, 98Frmts10RC.docGeert KnapenAdded the Transfer Delimiter concept.Cleaned up the formatting.1.0Mar 18, 98Frmts10.docGeert KnapenChanged all references to 1.0
`
`USB Device Class Definition for Audio Data FormatsRelease 1.0March 18, 1998
`
`Revision
`
`Date
`
`Filename
`
`Author
`
`Description
`
`ii
`
`Petitioners
`Exhibit 1011, Page 2
`
`This document is the 1.0 release of this device class definition.
`

`
`Copyright © 1997, USB Implementers Forum
`All 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.
`
`USB Device Class Definition for Audio Data FormatsRelease 1.0March 18, 1998
`
`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@usb.org
`
`iii
`
`Petitioners
`Exhibit 1011, Page 3
`
`

`
`Table of Contents
`
`Scope of This Release.........................................................................................................ii
`
`Contributors.........................................................................................................................ii
`
`Revision History ..................................................................................................................ii
`
`Table of Contents ...............................................................................................................iv
`
`List of Tables .......................................................................................................................v
`
`Introduction ..................................................................................................................6
`
`1
`
`USB Device Class Definition for Audio Data FormatsRelease 1.0March 18, 1998
`
`1.1Related Documents.................................................................................................61.2Terms and Abbreviations.........................................................................................6
`2 Audio Data Formats......................................................................................................8
`
`2.1Transfer Delimiter....................................................................................................82.2Type I Formats........................................................................................................82.2.1USB Packets....................................................................................................82.2.2Audio Subframe................................................................................................92.2.3Audio Frame.....................................................................................................92.2.4Audio Streams..................................................................................................92.2.5Type I Format Type Descriptor.......................................................................102.2.6Supported Formats.........................................................................................112.3Type II Formats.....................................................................................................122.3.1Encoded Audio Frames...................................................................................122.3.2Audio Bitstreams.............................................................................................122.3.3USB Packets..................................................................................................132.3.4Bandwidth Allocation.......................................................................................132.3.5Timing............................................................................................................132.3.6Type II Format Type Descriptor......................................................................132.3.7Rate feedback................................................................................................152.3.8Supported Formats.........................................................................................152.4Type III Formats....................................................................................................262.4.1Type III Format Type Descriptor.....................................................................26
`
`3 Adding New Audio Data Formats ..............................................................................28
`
`Appendix A. Additional Audio Device Class Codes .....................................................29
`
`A.1Audio Data Format Codes......................................................................................29A.1.1Audio Data Format Type I Codes....................................................................29A.1.2Audio Data Format Type II Codes...................................................................29A.1.3Audio Data Format Type III Codes..................................................................29A.2Format Type Codes...............................................................................................30A.1Format-Specific Control Selectors.........................................................................30A.3...................................................................................................................................30A.3.1MPEG Control Selectors.................................................................................30A.3.2AC-3 Control Selectors...................................................................................30
`
`iv
`
`Petitioners
`Exhibit 1011, Page 4
`
`

`
`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
`
`List of Tables
`
`USB Device Class Definition for Audio Data FormatsRelease 1.0March 18, 1998
`
`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
`
`v
`
`Petitioners
`Exhibit 1011, Page 5
`
`

`
`1
`
`Introduction
`
`The intention of this document is to describe in detail all the Audio Data Formats that are supported bythe Audio Device Class. This document is considered an integral part of
`Specification
`USB Audio Specification
`, although subsequent revisions of this document are independent of the revision evolution ofthe main
`. This is to easily accommodate the addition of new Audio DataFormats without impeding the core
`
`the Audio Device Class
`
`USB Audio Specification
`
`•
`
`•
`
`1.1 Related Documents
`USB Specification
`Universal Serial Bus Specification
`•
`).In particular, see Chapter 9, “USB Device Framework.”
`Universal Serial Bus Device Class Definition for Audio Data Formats
`USB Audio Data Formats
` (referred to in this documentas
`Universal Serial Bus Device Class Definition for Terminal Types
`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 fromhttp://www.atsc.org)
`• ANSI/IEEE-754 floating-point standard.
`• ISO/IEC 958 International Standard:
`• ISO/IEC 1937 standard.
`• ITU G.711 standard.
`
`USB Device Class Definition for Audio Data FormatsRelease 1.0March 18, 1998
`
` Digital Audio Interface and Annexes.
`
`1.2 Terms and Abbreviations
`
`This section defines terms used throughout this document. For additional terms that pertain to theUniversal Serial Bus, see Chapter 2, “Terms and Abbreviations,” in the
`
`Audio Frame
`
`Audio Stream
`
`Audio Subframe
`
`DVD
`
`Encoded Audio Bitstream
`
`Encoded Audio Frame
`
`MPEG
`
`PCM
`
`Transfer Delimiter
`
`USB Specification
`
`A collection of audio subframes, each containing a PCMaudio sample of a different physical audio channel, takenat the same moment in time.
`
`A concatenation of a potentially very large number ofaudio frames ordered according to ascending time.
`
`A concatenation of a potentially very large number ofencoded audio frames, ordered according to ascendingtime.
`
`A sequence of bits that contains an encoded representationof one or more physical audio channels.
`
`A unique token that indicates an interruption in anisochronous data packet stream. Can be either a zero-length data packet or the absence of an isochronoustransfer in a certain USB frame.
`
`
`
`
`
`
`
`6
`
`Petitioners
`Exhibit 1011, Page 6
`
`.
`, 1.0 final draft revision (also referred to as the
`).
` (referred to in this document as
`).
`.
`Holds a single PCM audio sample.
`Acronym for
`Digital Versatile Disc.
`Acronym for
`Moving Pictures Expert Group.
`Acronym for
`Pulse Coded Modulation.
`

`
`USB Device Class Definition for Audio Data FormatsRelease 1.0March 18, 1998
`
`7
`
`Petitioners
`Exhibit 1011, Page 7
`
`

`
`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 byconcatenating those symbols. Different compression schemes may be used to transform the audio samplesinto symbols. If multiple physical audio channels are formatted into a single audio channel cluster, thensamples at time
`
`x
` of subsequent channels are transmitted interleaved, according to the cluster channelordering as described in the main
`
`USB Audio Specification
`
`x
`
`+1, interleavedin the same fashion and so on. The notion of physical channels is explicitly preserved duringtransmission. 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 channelsduring the transmission. Typically, all non-PCM encoded audio data streams belong to this group. Anumber of audio samples, often originating from multiple physical channels, are encoded into a number ofbits in such a way that, after transmission, the original audio samples can be reconstructed to a certaindegree of accuracy. The number of bits used for transmission is typically one or more orders of magnitudesmaller than the number of bits needed to represent the original PCM audio samples, effectively realizinga considerable bandwidth reduction during transmission.The third group, Type III, contains special formats that do not fit in both previous groups. In fact, theymix characteristics of Type I and Type II groups to transmit audio data streams. One or more non-PCMencoded audio data streams are packed into “pseudo-stereo samples” and transmitted as if they were realstereo PCM audio samples. The sampling frequency of these pseudo samples matches the samplingfrequency of the original PCM audio data streams. Therefore, clock recovery at the receiving end is easierthan it is in the case of Type II formats. The drawback is that unless multiple non-PCM encoded streamsare 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 currentlysupported in the Audio Device Class. The following sections explain those formats in more detail.
`
`2.1 Transfer Delimiter
`
`USB Device Class Definition for Audio Data FormatsRelease 1.0March 18, 1998
`
`Isochronous data streams are continuous in nature, although the actual number of bytes sent per packetmay vary throughout the lifetime of the stream (for rate adaptation purposes for instance). To indicate atemporary stop in the isochronous data stream without closing the pipe (and thus relinquishing the USBbandwidth), an in-band Transfer Delimiter needs to be defined. This specification considers two situationsto be a Transfer Delimiter. The first is a zero-length data packet and the second is the absence of anisochronous transfer in a particular USB frame. Both situations are considered equivalent and the audiofunction is expected to behave the same. However, the second type consumes less isochronous USBbandwidth (i.e. zero bandwidth). In both cases, this specification considers a Transfer Delimiter to be anentity that can be sent over the USB.
`
`2.2 Type I Formats
`
`2.2.1 USB Packets
`
`The following sections describe the Audio Data Formats that belong to Type I. A number of terms andtheir definition are presented.
`
`Audio data streams that are inherently continuous must be packetized when sent over the USB. Thequality of the packetizing algorithm directly influences the amount of effort needed to reconstruct areliable sample clock at the receiving side. The goal must be to keep the instantaneous number of samples
`
`8
`
`Petitioners
`Exhibit 1011, Page 8
`
`, followed by samples at time
`

`
`ni
`
`nav
`
`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
` is limited to one sample, that is, D ni
`ni
`nav
`nav
` = 1.This implies that all packets must either contain INT (
`i
` ) + 1 (large packet)samples. For all
`
`Note
`
`ni
`nav
`nav
`ni
`nav
`nav
`nav
`)(medium packet) and INT (
`
`nav
`
`nav
`
`nav
`
`ni
`
`) + 1 (large packet).To limit the needed buffer depths to acceptable limits, this specification limits the cumulative differencebetween
` to –1.5 samples.If the sampling rate can be varied (to implement pitch control), the allowable pitch shift is 1kHz/ms. Thatis, the allowable variation on
` – 1Pitch control is restricted to adaptive endpoints only. AudioStreaming interfaces that support pitch controlon their isochronous endpoint are required to report this in the class-specific endpoint descriptor. Inaddition, a Set/Get Pitch Control request is required to enable or disable the pitch control functionality.
`
`ni
`
`i
`
`ni+1
`
`ni
`
`USB Device Class Definition for Audio Data FormatsRelease 1.0March 18, 1998
`
`2.2.2 Audio Subframe
`
`The basic structure used to represent audio data is the audio subframe. An audio subframe holds a singleaudio sample. An audio subframe always contains an integer number of bytes.This specification limits the possible audio subframe sizes (
`
`bSubframeSize
`bBitResolution
`) to 1, 2, 3 or 4 bytes per audiosubframe. An audio sample is represented using a number of bits (
`bBitResolution
`bSubframeSize
`
`) less than or equal tothe total number of bits available in the audio subframe, i.e. £
`
`*8.AudioStreaming endpoints must be constructed in such a way that a valid transfer can take place as longas the reported audio subframe size (
`bSubframeSize
`bBitResolution
`) is respected during transmission. If the reported bitsper sample (
`) do not correspond with the number of significant bits actually used duringtransfer, the device will either discard trailing significant bits ([actual_bits_per_sample] >bBitResolution
`bBitResolution
`
`2.2.3 Audio Frame
`
`An audio frame consists of a collection of audio subframes, each containing an audio sample of a differentphysical audio channel, taken at the same moment in time. The number of audio subframes in an audioframe equals the number of logical audio channels in the audio channel cluster. The ordering of the audiosubframes in the audio frame obeys the rules set forth in the
`
`USB Audio Specification
`. All audiosubframes 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 accordingto ascending time. Streams are packetized when transported over USB whereby USB packets can onlycontain an integer number of audio frames. Each packet always starts with the same channel, and thechannel order is respected throughout the entire transmission. If, for any reason, there are no audio framesavailable to construct a USB packet, a Transfer Delimiter must be sent instead.
`
`9
`
`Petitioners
`Exhibit 1011, Page 9
`
`per frame (
`) as close as possible to the average number of samples per frame, (
`). The average
`) (small packet) or INT (
`:
` = INT (
`) | INT (
`) + 1
`:In the case where
` = INT (
`),
`may vary between INT (
`) - 1 (small packet), INT (
` and
` is limited to one sample per frame. For all
`:
` =
`) or interpret trailing zeros as significant bits ([actual_bits_per_sample] <
`).
`

`
`2.2.5 Type I Format Type Descriptor
`
`bDescriptorSubtype
`.The
`bNrChannels
`bFormatType
`bSubframeSize
` field contains the numberof physical channels in the audio data stream. The
`bBitResolution
` field indicates how many bytes areused to transport an audio subframe. The
`
`bLength
`
`bDescriptorType
`
` field indicates how many bits of the totalnumber of available bits in the audio subframe are truly used by the audio function to convey audioinformation.The sampling frequency capabilities of the isochronous data endpoint of the AudioStreaming Interface arereported as well. Depending on the
`
`bSamFreqType
`
` field, the length of the descriptor varies and theinterpretation of the trailing fields differs. Sampling frequencies occupy three bytes and are expressed inHz to support over-sampled, reduced bit-resolution systems (the range is from 0 to 16,777,215 Hz).
`
`USB Device Class Definition for Audio Data FormatsRelease 1.0March 18, 1998
`
`Table 2-1: Type I Format Type Descriptor
`
`Offset
`
`Field
`
`Size
`
`Value
`
`Description
`
`0bLength1NumberSize of this descriptor, in bytes: 8+(ns*3)1bDescriptorType1ConstantCS_INTERFACE descriptor type.2bDescriptorSubtype1ConstantFORMAT_TYPE descriptor subtype.3bFormatType1ConstantFORMAT_TYPE_I. Constant identifyingthe Format Type the AudioStreaminginterface is using.4bNrChannels1NumberIndicates the number of physicalchannels in the audio data stream.5bSubframeSize1NumberThe number of bytes occupied by oneaudio subframe. Can be 1, 2, 3 or 4.6bBitResolution1NumberThe number of effectively used bits fromthe available bits in an audio subframe.7bSamFreqType1NumberIndicates how the sampling frequencycan be programmed:0:Continuous sampling frequency1..255:The number of discrete samplingfrequencies supported by theisochronous data endpoint of theAudioStreaming 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 asshown in the following tables.
`Table 2-2: Continuous Sampling Frequency
`
`Offset
`
`Field
`
`Size
`
`Value
`
`Description
`
`10
`
`Petitioners
`Exhibit 1011, Page 10
`
`The Type I format type descriptor starts with the usual three fields:
`,
`, and
` field indicates this is a Type I descriptor. The
`

`
`Offset
`
`Field
`
`Size
`
`Value
`
`Description
`
`8tLowerSamFreq3NumberLower bound in Hz of the samplingfrequency range for this isochronous dataendpoint.11tUpperSamFreq3NumberUpper bound in Hz of the samplingfrequency range for this isochronous dataendpoint.
`
`Table 2-3: Discrete Number of Sampling Frequencies
`
`Offset
`
`Field
`
`Size
`
`Value
`
`Description
`
`8tSamFreq [1]3NumberSampling frequency 1 in Hz for thisisochronous data endpoint.……………8+(ns-1)*3tSamFreq [ns]3NumberSampling frequency ns in Hz for thisisochronous data endpoint.
`
`Note
`
`:In the case of adaptive isochronous data endpoints that support only a discrete number ofsampling frequencies, the endpoint must at least tolerate –1000 PPM inaccuracy on thereported sampling frequencies.
`
`2.2.6 Supported Formats
`
`2.2.6.1 PCM Format
`
`The PCM (Pulse Coded Modulation) format is the most commonly used audio format to represent audiodata streams. The audio data is not compressed and uses a signed two’s-complement fixed point format. Itis left-justified (the sign bit is the Msb) and data is padded with trailing zeros to fill the remaining unusedbits of the subframe. The binary point is located to the right of the sign bit so that all values lie within therange [-1,+1).
`
`2.2.6.2 PCM8 Format
`
`bBitResolution
`The PCM8 format is introduced to be compatible with the legacy 8-bit wave format. Audio data isuncompressed and uses 8 bits per sample (
`= 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
`
`USB Device Class Definition for Audio Data FormatsRelease 1.0March 18, 1998
`
`The IEEE_FLOAT format is based on the ANSI/IEEE-754 floating-point standard. Audio data isrepresented using the basic single-precision format. The basic single-precision number is 32 bits wide andhas an 8-bit exponent and a 24-bit mantissa. Both mantissa and exponent are signed numbers, but neitheris represented in two's-complement format. The mantissa is stored in sign magnitude format and theexponent in biased form (also called excess-n form). In biased form, there is a positive integer (called thebias) which is subtracted from the stored number to get the actual number. For example, in an eight-bitexponent, the bias is 127. To represent 0, the number 127 is stored. To represent -100, 27 is stored. An
`
`11
`
`Petitioners
`Exhibit 1011, Page 11
`
`The following paragraphs list all currently supported Type I Audio Data Formats.
`

`
`exponent of all zeroes and an exponent of all ones are both reserved for special cases, so in an eight-bitfield, exponents of -126 to +127 are possible. In the basic floating-point format, the mantissa is assumedto be normalized so that the most significant bit is always one, and therefore is not stored. Only thefractional part is stored.The 32-bit IEEE-754 floating-point word is broken into three fields. The most significant bit stores thesign of the mantissa, the next group of 8 bits stores the exponent in biased form, and the remaining 23 bitsstore the magnitude of the fractional portion of the mantissa. For further information, refer to theANSI/IEEE-754 standard.The data is conveyed over USB using 32 bits per sample (
`
`bBitResolution
`
`bSubframeSize
`
`2.2.6.4 ALaw Format and mm Law Format
`
`bBitsPerSample
`
`Starting from 12- or 16-bits linear PCM samples, simple compression down to 8-bits per sample (one byteper sample) can be achieved by using logarithmic companding. The compressed audio data uses 8 bits persample (
`= 8). Data is signed fixed point, left-justified in the subframe, Msb first. Thecompressed range is [-128,128]. The difference between Alaw and mLaw compression lies in the formulaeused 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 asequence of encoded audio frames.
`
`2.3.1 Encoded Audio Frames
`
`USB Device Class Definition for Audio Data FormatsRelease 1.0March 18, 1998
`
`An encoded audio frame is a sequence of bits that contains an encoded representation of one or morephysical audio channels. The encoding takes place over a fixed number of audio samples. Each encodedaudio 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 neededduring decoding. The number of samples used to construct one encoded audio frame depends on theencoding scheme. (For MPEG, the number of samples per encoded audio frame (nf) is 384 for Layer I or1152 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 bitsper encoded audio frame may be variable. The content of the encoded audio frame is defined according tothe implemented encoding scheme. Where applicable, the bit ordering shall be MSB first, relative toexisting standards of serial transmission or storage of that encoding scheme. An encoded audio framerepresents an interval longer than the USB frame time of 1 ms. This is typical of audio compressionalgorithms 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, “AudioFrame”) and an encoded audio frame. The overloaded use of the term audio frame could causeconfusion. Therefore, this specification will always use the qualifier ‘encoded’ to refer toMPEG 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 audioframes, ordered according to ascending time. Subsequent encoded audio frames are independent and canbe decoded separately.
`
`12
`
`Petitioners
`Exhibit 1011, Page 12
`
` = 32;
` = 4).
`

`
`USB Device Class Definition for Audio Data FormatsRelease 1.0March 18, 1998
`
`2.3.3 USB Packets
`
`Encoded audio bitstreams are packetized when transported over an isochronous pipe. Each USB packetcontains only part of a single encoded audio frame. Packet sizes are determined according to the short-packet protocol. The encoded audio frame is broken down into a number of packets, each containingwMaxPacketSize
`
`bmAttributes
`MaxPacketsOnly
` bytes except for the last packet, which may be smaller and contains the remainder ofthe encoded audio frame. If the
` field of the class-specificendpoint 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 audioframe length is not a multiple of 8 bits, the last byte in the last packet is padded with zero bits. Thedecoder must ignore all padded extra bits and bytes. Consecutive encoded audio frames are separated by atleast one Transfer Delimiter. A Transfer Delimiter must be sent in all consecutive USB frames until thenext encoded audio frame is due. The above rules guarantee that a new encoded audio frame always startson a USB packet boundary.
`
`2.3.4 Bandwidth Allocation
`nf
`tf
`fs
` dividedby the sampling rate
`
`wMaxPacketSize
`
`sf
`
`fn
`
`t =
`
`f
`
` of the original audio samples.The allocated bandwidth for the pipe must accommodate for the largest possible encoded audio frame tobe transmitted within an encoded audio frame time. This should take into account the Transfer Delimiterrequirement and any differences between the time base of the stream and the USB frame timer. The devicemay choose to consume more bandwidth than necessary (by increasing the reported
`
`) tominimize the time needed to transmit an entire encoded audio frame. This can be used to enable earlydecoding 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 thatcontains the first bits (usually the encoded audio frame sync word) of the encoded audio frame is used as atiming reference in USB space. This USB packet is called the reference packet. The transmission of thereference packet of an encoded audio frame should begin at the target playback time of that frame (minusthe endpoint’s reported delay) rounded to the nearest USB frame time. This guarantees that, at thereceiving end, the arrival of subsequent reference packets matches the encoded audio frame time
`
`tf
` asclosely as possible.
`
`2.3.6 Type II Format Type Descriptor
`
`bLength
`
`bDescriptorType
`
`wMaxBitRate
`
`bDescriptorSubtype
`.The
`bFormatType
` field contains themaximum number of bits per second this interface can handle. It is a measure for the buffer size availablein the interface. The
` field contains the number of non-PCM encoded audio samplescontained within a single encoded audio frameThe sampling frequency capabilities of the endpoint are reported using the
`
`wSamplesPerFrame
`
`bSamFreqType
` field andfollowing fields.
`Table 2-4: Type II Format Type Descriptor
`
`Offset
`
`Field
`
`Size
`
`Value
`
`Description
`
`13
`
`Petitioners
`Exhibit 1011, Page 13
`
` bit D7 in the
`The encoded audio frame time
` equals the number of audio samples per encoded audio frame
`The Type II Format Type descriptor starts with the usual three fields
`,
` and
` field indicates this is a Type II descriptor. The
`

`
`Offset
`
`Field
`
`Size
`
`Value
`
`Description
`
`0bLength1NumberSize of this descriptor, in bytes: 9+(ns*3)1bDescriptorType1ConstantCS_INTERFACE descriptor

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket