USB Device Class Definition for Audio Devices
Release 1.0 March 18, 1998 26
· Reverb Level: sets the amount of reverberant sound.
· Reverb Time: sets the time over which the reverberation will continue.
· Reverb Delay Feedback: used with Reverb Types Delay and Delay Panning. Sets the way in which delay repeats
The effects of the Reverberation Processing Unit can be bypassed at all times through manipulation of the Enable Processing Control.
In principle, the algorithm to produce the desired reverberation effect influences all channels as a whole. It is entirely left to the designer how a certain reverberation effect is obtained. It is not the intention of this specification to precisely define all the parameters that influence the reverberation experience (for instance in a multi-channel system, it is possible to create very similar reverberation impressions, using different algorithms and parameter settings on all channels).
The symbol for the Reverberation Processing Unit can be found in the following figure:
Figure 3-9: Reverberation Processing Unit Icon
3.5.6.5 Chorus Processing Unit
The Chorus Processing Unit is used to add chorus effects to the original audio information. A number of parameters can be manipulated to obtain the desired chorus effects.
· Chorus Level: controls the amount of the effect sound of chorus.
· Chorus Modulation Rate: sets the speed (frequency) of the modulator of the chorus.
· Chorus Modulation Depth: sets the depth at which the chorus sound is modulated.
The effects of the Chorus Processing Unit can be bypassed at all times through manipulation of the Enable Processing Control.
In principle, the algorithm to produce the desired chorus effect influences all channels as a whole. It is entirely left to the designer how a certain chorus effect is obtained. It is not the intention of this specification to precisely define all the parameters that influence the chorus experience.
The symbol for the Chorus Processing Unit can be found in the following figure:
Figure 3-10: Chorus Processing Unit Icon
3.5.6.6 Dynamic Range Compressor Processing Unit
The Dynamic Range Compressor Processing Unit is used to intelligently limit the dynamic range of the original audio information. A number of parameters can be manipulated to influence the desired compression.
USB Device Class Definition for Audio Devices
Release 1.0 March 18, 1998 27
Figure 3-11: Dynamic Range Compressor Transfer Characteristic
· Compression ratio R: determines the slope of the static input-to-output transfer characteristic in the compressor’s active input range. The compression is defined in terms of the compression ratio R, which is the inverse of the derivative of the output power PO as a function of the input power PI when PO and PI are expressed in dB.
PR is the reference level and it is made equal to the so-called line level. All levels are expressed relative to the line level (0 dB), which is usually 15-20 dB below the maximum level. Compression is obtained when R > 1, R = 1 does not affect the signal and R < 1 gives rise to expansion.
· Maximum Amplitude: the upper boundary of the active input range, relative to the line level (0 dB). Expressed in dB.
· Threshold level: the lower boundary of the active input level, relative to the line level (0 dB).
· Attack Time: determines the response of the compressor as a function of time to a step in the input level. Expressed in ms.
· Release Time: relates to the recovery time of the gain of the compressor after a loud passage. Expressed in ms.
The effects of the Dynamic Range Compressor Processing Unit can be bypassed at all times through manipulation of the Enable Processing Control.
In principle, the algorithm to produce the desired dynamic range compression influences all channels as a whole. It is entirely left to the designer how a certain dynamic range compression is obtained.
The symbol for the Dynamic Range Compressor Processing Unit can be found in the following figure:
{{Figure 3-12: Dynamic Range Compressor Processing Unit Icon｝｝
USB Device Class Definition for Audio Devices
Release 1.0 March 18, 1998 28
3.5.7 Extension Unit
The Extension Unit (XU) is the method provided by this specification to easily add vendor-specific building blocks to the specification. The Extension Unit provides one or more logical input channels, grouped into one or more audio channel clusters and transforms them into a number of logical output channels, grouped into one audio channel cluster. Therefore, the Extension Unit can have multiple Input Pins and has a single Output Pin.
Extension Units are required to support at least the Enable Processing Control, allowing the Host software to bypass whatever functionality is incorporated in the Extension Unit.
Although a generic audio driver will not be able to determine what functionality is implemented in the Extension Unit, let alone manipulate it, it still will be capable of recognizing the presence of vendorspecific extensions and assume default behavior for those units.
The symbol for the Extension Unit can be found in the following figure:
Figure 3-13: Extension Unit Icon
3.5.8 Associated Interfaces
In some cases, an audio function building block (Terminal, Mixer Unit, Feature Unit, and so on) needs to be associated with interfaces that are not part of the Audio Interface Collection. As an example, consider a speaker system with front-panel volume knob. The manufacturer might want to impose a binding between the front-panel volume Control and the speaker system’s volume setting. The volume knob could be represented by a HID interface that coexists with the Audio Interface Collection. To create a binding between the Feature Unit inside the audio function that deals with master Volume Control and the frontpanel volume knob, the Feature Unit descriptor can be supplemented by a special Associated Interface descriptor that holds a link to the associated HID interface.
In general, each Terminal or Unit descriptor can be supplemented by one or more optional Associated Interface descriptors that hold a reference to an interface. This interface is external to the audio function and interacts in a certain way with the Terminal or Unit. The layout of the Associated Interface descriptor is open-ended and is qualified by the Entity type it succeeds and by the target interface Class type it references.
For the time being, this specification does not define any specific Associated Interface descriptor layout.
3.6 Copy Protection
Because the Audio Device Class is primarily dealing with digital audio streams, the issue of protecting these – often-copyrighted – streams can not be ignored. Therefore, this specification provides the means to preserve whatever copyright information is available. However, it is the responsibility of the Host software to manage the flow of copy protection information throughout the audio function.
Copy protection issues come into play whenever digital audio streams enter or leave the audio function. Therefore, the copy protection mechanism is implemented at the Terminal level in the audio function. Streams entering the audio function can be accompanied by specific information, describing the copy protection level of that audio stream. Likewise, streams leaving the audio function should be accompanied by the appropriate copy protection information, if the hardware permits it. This specification provides for two dedicated requests that can be used to manage the copy protection mechanism. The Get Copy Protect
USB Device Class Definition for Audio Devices
Release 1.0 March 18, 1998 29
request can be used to retrieve copy protection information from an Input Terminal whereas the Set Copy Protect request is used to preset the copy protection level of an Output Terminal.
This specification provides for three levels of copy permission, similar to CGMS (Copy Generation Management System) and SCMS (Serial Copy Management System).
· Level 0: Copying is permitted without restriction. The material is either not copyrighted, or the copyright is not asserted.
· Level 1: One generation of copies may be made. The material is copyright protected and is the original.
· Level 2: The material is copyright protected and no digital copying is permitted.
3.7 Operational Model
A device can support multiple configurations. Within each configuration can be multiple interfaces, each possibly having alternate settings. These interfaces can pertain to different functions that co-reside in the same composite device. Even several independent audio functions can exist in the same device. Interfaces, belonging to the same audio function are grouped into an Audio Interface Collection. If the device contains multiple independent audio functions, there must be multiple Audio Interface Collections, each providing full access to their associated audio function.
As an example of a composite device, consider a PC monitor equipped with a built-in stereo speaker system. Such a device could be configured to have one interface dealing with configuration and control of the monitor part of the device (HID Class), while a Collection of two other interfaces deals with its audio aspects. One of those, the AudioControl interface, is used to control the inner workings of the function (Volume Control etc.) whereas the other, the AudioStreaming interface, handles the data traffic, sent to the monitor’s audio subsystem.
The AudioStreaming interface could be configured to operate in mono mode (alternate setting x) in which only a single channel data stream is sent to the audio function. The receiving Input Terminal could duplicate this audio stream into two logical channels, and those could then be reproduced on both speakers. From an interface point of view, such a setup requires one isochronous endpoint in the AudioStreaming interface to receive the mono audio data stream, in addition to the mandatory control endpoint and optional interrupt endpoint in the AudioControl interface.
The same system could be used to play back stereo audio. In this case, the stereo AudioStreaming interface must be selected (alternate setting y). This interface also consists of a single isochronous endpoint, now receiving a data stream that interleaves left and right channel samples. The receiving Input Terminal now splits the stream into a Left and Right logical channel. The AudioControl interface remains unchanged. If the above AudioStreaming interface were an asynchronous sink, one extra isochronous synch endpoint would also be necessary.
Audio Interface Collections can be dynamic. Because the AudioControl interface, together with its associated AudioStreaming interface(s), constitute the ‘logical interface’ to the audio function, they must all come into existence at the same moment in time.
As stated earlier, audio functionality is located at the interface level in the device class hierarchy. The following sections describe the Audio Interface Collection, containing a single AudioControl interface and optional AudioStreaming interfaces, together with their associated endpoints that are used for audio function control and for audio data stream transfer.
USB Device Class Definition for Audio Devices
Release 1.0 March 18, 1998 30
3.7.1 AudioControl Interface
To control the functional behavior of a particular audio function, the Host can manipulate the Units and Terminals inside the audio function. To make these objects accessible, the audio function must expose a single AudioControl interface. This interface can contain the following endpoints:
· A control endpoint for manipulating Unit and Terminal settings and retrieving the state of the audio function. This endpoint is mandatory, and the default endpoint 0 is used for this purpose.
· An interrupt endpoint for status returns. This endpoint is optional.
The AudioControl interface is the single entry point to access the internals of the audio function. All requests that are concerned with the manipulation of certain audio Controls within the audio function’s Units or Terminals must be directed to the AudioControl interface of the audio function. Likewise, all descriptors related to the internals of the audio function are part of the class-specific AudioControl interface descriptor.
The AudioControl interface of an audio function may support multiple alternate settings. Alternate settings of the AudioControl interface could for instance be used to implement audio functions that support multiple topologies by presenting different class-specific AudioControl interface descriptors for each alternate setting.
3.7.1.1 Control Endpoint
The audio interface class uses endpoint 0 (the default pipe) as the standard way to control the audio function using class-specific requests. These requests are always directed to one of the Units or Terminals that make up the audio function. The format and contents of these requests are detailed further in this document.
3.7.1.2 Status Interrupt Endpoint
A USB AudioControl interface can support an optional interrupt endpoint to inform the Host about the status the status of the different addressable Entities (Terminals, Units, interfaces and endpoints) inside the audio function. In fact, the interrupt endpoint is used by the entire Audio Interface Collection to convey status information to the Host. It is considered part of the AudioControl interface because this is the anchor interface for the Collection.
The interrupt data is a 2-byte entity. The bStatusType field contains information in D7 indicating whether there is still an interrupt pending or not. This bit remains set until all pending interrupts are properly serviced. The other bits are used to report the cause of the interrupt in more detail. Bit D6 of the bStatusType field indicates a change in memory contents on one of the addressable Entities inside the audio function. This bit is cleared by a Get Memory request on the appropriate Entity. Bits D3..0 indicate the originator of the current interrupt. All addressable Entities inside an audio function can be originator.
The contents of the bOriginator field must be interpreted according to the code in D3..0 of the bStatusType field. If the originator is the AudioControl interface, the bOriginator field contains the TerminalID or UnitID of the Entity that caused the interrupt to occur. If the bOriginator field is set to zero, the ‘virtual’ Entity interface is the originator. This can be used to report global AudioControl interface changes to the Host. If the originator is an AudioStreaming interface, the bOriginator field contains the interface number of the AudioStreaming interface. Likewise, it contains the endpoint number if the originator were an AudioStreaming endpoint.
The proper response to an interrupt is either a Get Status request (D6=0) or a Get Memory request (D6=1). Issuing these requests to the appropriate originator must clear the Interrupt Pending bit and the Memory Contents Changed bit, if applicable.
The following table specifies the format of the status word:
最終更新：2011年05月22日 11:07
