Stream under-run/over-run recovery

Machine-readable media, methods, and apparatus are described to recover from stream under-run and/or over-run conditions. In some embodiments, an audio controller may discard any partial sample block of the stream.

BACKGROUND

An audio codec may provide an audio controller with more samples than the audio controller was programmed to accept. If the audio controller is unable to accept the additional samples, then the additional samples may be lost due to the over-run. Conversely, if the audio codec provides the audio controller with less data than the audio controller was programmed to accept, then the audio controller may interpret other data from the audio codec as one or more samples due to the under-run. Both under-run and over-run conditions may result in reduced audio quality and/or error conditions.

DETAILED DESCRIPTION

The following description describes data streaming techniques. In the following description, numerous specific details such as logic implementations, opcodes, means to specify operands, resource partitioning/sharing/duplication implementations, types and interrelationships of system components, and logic partitioning/integration choices are set forth in order to provide a more thorough understanding of the present invention. It will be appreciated, however, by one skilled in the art that the invention may be practiced without such specific details.

In other instances, control structures, gate level circuits and full software instruction sequences have not been shown in detail in order not to obscure the invention. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.

An embodiment of a computing device is shown inFIG. 1. The computing device may comprise a processor100and a chipset102coupled to one another via a processor bus104. The chipset102may comprise one or more integrated circuit packages or chips that couple the processor100to memory106and an audio controller108. The chipset102may further couple the processor to other components110of the computing device such as, for example, BIOS firmware, keyboards, mice, storage devices, network interfaces, etc via one or more buses112. In one embodiment, the chipset102may include a memory controller114to access memory106via a memory bus116. The memory controller114may access the memory106in response to memory transactions associated with the processor100, the audio controller108, and other components110of the computing device. Further, the memory106may comprise various memory devices that provide addressable storage locations which the memory controller114may read data from and/or write data to. In particular, the memory106may comprise one or more different types of memory devices such as, for example, DRAM (Dynamic Random Access Memory) devices, SDRAM (Synchronous DRAM) devices, DDR (Double Data Rate) SDRAM devices, or other memory devices.

The audio controller108may control the flow of data between the memory106and audio codecs118. The audio controller108may be integrated in the chipset102. However, as depicted, the audio controller108may also be separate from the chipset102. In such an embodiment, the audio controller108may comprise a bus interface120, a link controller122, and one or more DMA (direct memory access) controllers124. The bus interface120of the audio controller108may couple the audio controller108to a bus interface120of the chipset102in order to interface the audio controller108to the memory106coupled to the memory controller114of the chipset102.

The link controller122may provide the audio controller108with an interface to an audio bus126and the codecs118coupled to the audio bus126by controlling links between the audio controller108and the codecs118. In one embodiment, the audio bus126may comprise one or more point-to-point serial input links from each codec118to the audio controller108. The audio bus126may further comprise a broadcast serial output link from the audio controller108to the codecs118. The link controller122may generate and receives frames128via the links of the audio bus126in accordance to an audio bus protocol.

In one embodiment, each DMA controller124may be separately programmed by the processor100to stream data between a buffer of the memory106and one or more audio codecs118. The audio codecs118may correspond to sound cards, modems, fax machines, audio capture devices, etc that are incorporated and/or otherwise coupled to the computing device. In one embodiment, the audio codecs118may be integrated into the chipset102, may be mounted to a mainboard of the computing device, may be mounted to an add-in card that is coupled to the computing device, and/or may be part of an external device such as, for example, a docking station, audio mixer, etc that is coupled to an interface port (not shown) of the computing device.

As illustrated inFIG. 2, the link controller122may receive audio streams from a codec118via frames128defined by control signals130of an audio bus control link and data signals132of an audio bus serial data input link. In particular, the control signals130may comprise frame syncs134to indicate the start of a frame128. As illustrated, a frame128may comprise a command/response136, one or more stream tags138, one or more packets140and an optional null field142. The command/response136may comprise a command that requests a receiver of the frame128to perform some action and/or may comprise a response to a command of a previous frame128.

In general, the stream tags138may indicate the start of a packet140, may identify to which stream the packet140is associated, and may indicate a length of the packet140. In one embodiment, each stream tag138of the frame128may comprise a stream identifier (ID)144that indicates to which stream the packet140is associated. Further, each stream tag138may comprise an actual packet length146that indicates the length (e.g. number of bytes) of the following packet140. The stream tags138may permit a codec118to transfer multiple streams and/or multiple packets140of a single stream during a single frame128. Further, the null field142may comprise pad bits/bytes that extend the frame128to a fixed length or a multiple of some frame unit length. In another embodiment, the null field142may be associated with a quiescent period of an audio link in which no data is transmitted.

As shown, each packet140may comprise one or more sample blocks148and an optional null pad150. The null pad150may pad the packet140to a fixed packet length or to a multiple of some packet unit length. In another embodiment, the null pad150may be associated with a quiescent period of an audio link in which no data is transmitted. Each sample block148of a packet140may comprise a separate sample152for each channel of a plurality of channels. For example, a stereo sample block148may comprise right channel sample152and left channel sample152that are associated with the same sample point in time of a stereo audio signal. Similarly, a 5.1 sample block148may comprise center channel sample152, front right channel sample152, front left channel sample152, back right channel sample152, back right channel sample152, and bass channel sample152that are associated with the same sample point in time of a 5.1 channel audio signal.

In one embodiment, the processor100may program the audio controller108with characteristics of a stream to be transferred from a codec118to a buffer of the memory106. In particular, the processor100may assign a DMA controller124to the stream, may set a sample length (e.g. a number of bits per sample152), may set a sample block length (e.g. a number of bytes or a number of samples152per sample block148), and may set an expected packet length (e.g. a number of sample blocks or a number of bytes per packet140) to indicate an amount the codec118is expected to send during each packet140.

In such an environment, an over-run may occur if the codec118sends a packet140having an actual packet length146greater than the expected packet length the audio controller108was configured to accept. In one embodiment, the audio controller108may recover from the above over-run by accepting the extra sample blocks148of the packet140because the extra sample blocks148are valid sample blocks148of the packet140. An over-run/under-run may also occur if the codec118sends a packet140having an actual packet length146that is a non-integer multiple of the sample block length. In one embodiment, the audio controller108may recover from the over-run/under-run condition by dropping or discarding any partial sample block148. Further, an under-run may occur if the codec118sends a packet140having an actual packet length146that is less than the expected packet length that the audio controller124was configured to accept. In one embodiment, the audio controller124may recover from the above under-run condition by only accepting the sent sample blocks148of the packet140since the sent sample blocks148are the only valid sample blocks148of the packet140.

Shown inFIG. 3is an embodiment of a method of the audio controller108to recover from stream over-runs and/or under-runs. In box200, the processor100may program the audio controller108and/or the audio controller108may be otherwise configured to handle an audio stream of a codec118. In one embodiment, the processor100may assign a stream to a DMA controller124of the audio controller108by providing the link controller122and/or the DMA controller124with a stream ID144for the stream. Further, the processor100may provide the link controller and/or the DMA controller124with a sample length, a sample block length, and an expected packet length of the stream.

In box202, the audio controller108may receive from the codec118a stream tag138having a stream ID144and an actual packet length146that indicates the number of bytes of the packet140associated with the stream tag138. The link controller122in box204may update a TBR (To Be Received) value based upon the received actual packet length146. In one embodiment, the link controller122may update the TBR value by setting the TBR value equal to the received actual packet length146to indicate the number of bytes of the packet140yet to be received.

In box206, the link controller122may determine whether the end of packet140has been reached. In one embodiment, the link controller122may determine that the end of the packet140has been reached based upon the TBR value for the packet140. In particular, the link controller122may determine that the end of the packet140has been reached in response to the TBR value having a predetermined relationship (e.g. less than or equal) to a packet end value (e.g. 0). The link controller122may also determine that the end of the packet140has been reached in response to detecting a frame sync134that signals the start of the another frame128and/or a stream tag138that signals the start of another packet140of the frame128.

In response to detecting the end of the packet140, the link controller122in box208may cause the DMA controller124assigned to the stream of the received packet140to transfer the received complete sample blocks148to a buffer of the memory106. As depicted, the DMA controller124may wait until the end of a stream prior to transferring the complete sample blocks148to the memory106which may increase the efficiency of the transfer to memory106. However, in other embodiments, the DMA controller124may transfer the complete sample blocks148to memory106more frequently in order to reduce latency between when complete sample blocks148are received and when the complete sample blocks148are available in the memory106.

However, if the link controller122does not detect the end of the packet140, the link controller122may determine in box210whether one or more additional complete sample blocks148of the packet140may yet be received. In one embodiment, the link controller122may determine that additional complete sample blocks148may be received based upon the TBR value. In particular, the audio controller may determine that additional complete sample blocks148of the packet140may be received in response to determining that the TBR value has a predetermined relationship (e.g. less than or equal) to the sample block length of the packet140. In response to determining that additional complete sample blocks148may not be received, the link controller122in box212may discard a partial sample block by discarding any received packet data until the end of the packet140is detected. In one embodiment, the link controller122may determine that the end of the packet140has been reached in response to detecting a frame sync134that signals the start of the next frame128, a stream tag138that signals the start of another packet140of the frame128, or the TBR value indicates the end of the current packet140.

The link controller122in box214may buffer data received from the audio codec118and may monitor the control signal130for synchronization events such as, for example, frame syncs. In box216, the link controller122may determine whether a complete sample block148has been received. In one embodiment, the link controller122may classify a sample block148having a defined number of bytes as a complete sample block148and a sample block148having less than the defined number of bytes as a partial sample block. In response to determining that a complete sample block148has been received, the DMA controller124in box218may accept the complete sample block148and may update the TBR value accordingly. In one embodiment, the DMA controller124may update the TBR value by subtracting the sample block length or the number of bytes of the complete sample block148from the TBR value. The DMA controller124may then return to box206in order to determine whether the end of the packet140has been reached. In response to determining that only a partial sample block148has been received thus far, the DMA controller124may return to box214in order to receive the remainder of the sample block148.

Certain features of the invention have been described with reference to example embodiments. However, the description is not intended to be construed in a limiting sense. Various modifications of the example embodiments, as well as other embodiments of the invention, which are apparent to persons skilled in the art to which the invention pertains are deemed to lie within the spirit and scope of the invention.