Wireless transmission and reception of packetized audio data in combination with forward error correction

Abstract

To provide methods for transmitting and receiving an audio stream.SOLUTION: For transmission, a method involves obtaining a frame of an audio signal, and determining a number of source blocks to divide the frame of the audio signal into and a number of parity blocks to generate for forward error correction. The number of source blocks and the number of parity blocks are determined based on characteristics of a wireless communication protocol to be used. The wireless communication protocol may be BLUETOOTH. The parity blocks are usable by a decoder to reconstruct one or more corrupted or missing source blocks and may be obtained by means of Reed-Solomon encoding.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to the following priority applications: U.S. Provisional Application No. 63 / 195,781 (Docket No. D21054USP1), filed June 2, 2021, and U.S. Provisional Application No. 63 / 363,855 (Docket No. D21054USP2), filed April 29, 2022, which are incorporated herein by reference.

[0002] Technical Field The present disclosure relates to systems, methods, and media for wireless audio stream transmission. [Background technology]

[0003] With the increasing use of network-connected home speaker devices, home theaters, and wireless speakers and headphones, users are increasingly using wireless communication channels for media content playback. Reliability of audio transport using wireless communication channels is important. In many wireless communication protocols, corrupted or missing audio packets are retransmitted by the transmitter device to the receiver device. However, retransmission of corrupted or missing audio packets can be harmful. For example, packet retransmission can cause audio content to become unsynchronized with video content. As another example, packet retransmission can cause real-time audio content (e.g., telephone or video conference conversations) to be distorted or have delays. Therefore, improved systems, methods, and media for wireless audio stream transmission are desired.

[0004] Notation and Nomenclature Throughout this disclosure, including the claims, the terms "speaker," "loudspeaker," and "audio reproduction transducer" are used interchangeably to refer to any sound-emitting transducer (or set of transducers). A typical headphone set includes two speakers. A speaker may be implemented to include multiple transducers (e.g., woofers and tweeters) that may be driven by a single common speaker feed or multiple speaker feeds. In some examples, the speaker feeds may undergo different processing in different circuit branches coupled to different transducers.

[0005] Throughout this disclosure, including the claims, the phrase performing an operation "on" a signal or data (e.g., filtering, scaling, transforming, or applying a gain to the signal or data) is used broadly to indicate performing an operation on the signal or data directly, or on a processed version of the signal or data (e.g., on a version of the signal that has undergone preliminary filtering or preprocessing before the operation is performed).

[0006] Throughout this disclosure, including the claims, the term "system" is used broadly to refer to a device, system, or subsystem. For example, a subsystem that implements a decoder may be referred to as a decoder system, and a system that includes such a subsystem (e.g., a system that generates X output signals in response to multiple inputs, where the subsystem generates M of the inputs and the other XM inputs are received from external sources) may also be referred to as a decoder system.

[0007] Throughout this disclosure, including the claims, the term "processor" is used broadly to denote a system or device that is programmable or configurable (e.g., with software or firmware) to perform operations on data (e.g., audio, video, or other image data). Examples of processors include field programmable gate arrays (or other configurable integrated circuits or chipsets), digital signal processors programmed and / or otherwise configured to perform pipeline processing on audio or other sound data, programmable general-purpose processors or computers, and programmable microprocessor chips or chipsets. Summary of the Invention [Means for solving the problem]

[0008] At least some aspects of the present disclosure may be implemented via methods. Some methods may include obtaining a frame of an audio signal. Some methods may include determining a number of source blocks into which to divide the frame of the audio signal and a number of parity blocks to generate for forward error correction, where the number of source blocks and the number of parity blocks are determined based at least in part on characteristics of a wireless communication protocol to be used to transmit the audio stream. Some methods may include dividing the frame of the audio signal into the number of source blocks. Some methods may include generating the number of parity blocks using the source blocks. Some methods may include transmitting the source blocks and the parity blocks, where the parity blocks are usable by a decoder to reconstruct one or more corrupted or missing source blocks.

[0009] In some instances, the parity blocks are generated using a Reed-Solomon encoder.

[0010] In some examples, the characteristics of the wireless communication protocol include timing information indicating packet scheduling of the wireless communication protocol. In some examples, determining the number of parity blocks includes: determining a total number of blocks to be used to encode the frame of the audio signal based on the duration of the frame of the audio signal and the timing information indicating packet scheduling; determining a number of source blocks; and determining the number of parity blocks by determining a difference between the total number of blocks and the number of source blocks.

[0011] In some examples, the characteristics of the wireless communication protocol include a frame size of a frame of the audio signal and / or a packet size of a packet to be used to transmit a source block of the source blocks or a parity block of the parity blocks, and in some examples, the number of source blocks to be used is determined by determining a number of packets each having the packet size for transmitting a frame having the frame size.

[0012] In some instances, the number of parity blocks identified for a frame of the audio signal differs from the number of parity blocks generated for a preceding frame of the audio signal.

[0013] In some examples, the number of parity blocks generated for a frame of the audio signal varies in a repeatable manner determined based on timing information indicative of packet scheduling of a wireless communication protocol.

[0014] In some examples, frames of an audio signal are not retransmitted in response to portions of the frame being dropped or corrupted.

[0015] In some examples, the wireless communication protocol is the BLUETOOTH® protocol.

[0016] Some methods may include receiving a set of source blocks and a set of parity blocks corresponding to a frame of an audio signal using a wireless communication protocol connection, where the set of source blocks is at least a subset of the source blocks generated by an encoder, and the set of parity blocks is at least a subset of the parity blocks generated by the encoder, and the number of source blocks and parity blocks generated and transmitted by the encoder are determined at least in part based on characteristics of the wireless communication protocol. Some methods may include determining a number of corrupted source blocks among the set of source blocks. Some methods may include determining whether to reconstruct the corrupted source blocks in response to determining that the number of corrupted source blocks is greater than zero. Some methods may include reconstructing the corrupted source blocks in response to determining that the corrupted source blocks should be reconstructed. Some methods may include presenting a version of the audio frame including the reconstructed corrupted source blocks.

[0017] In some examples, determining whether to reconstruct corrupted source blocks includes determining whether the number of corrupted source blocks is less than the number of uncorrupted parity blocks in the set of received parity blocks.

[0018] In some examples, some methods may further include receiving a second set of source blocks and a second set of parity blocks corresponding to a second frame of the audio signal; determining a second number of corrupted source blocks in the second set of source blocks; generating a replacement audio frame in response to determining that the second number of corrupted source blocks in the second set of source blocks is greater than the number of parity blocks in the second set of parity blocks; and presenting the replacement audio frame. In some examples, the replacement audio frame includes a reduction in an output level of the audio signal.

[0019] In some examples, reconstructing the corrupted source blocks involves providing the set of source blocks and the set of parity blocks to a Reed-Solomon decoder.

[0020] In some examples, some methods may further include storing the set of source blocks and the set of parity blocks in a buffer before reconstructing the corrupted source blocks, wherein the amount of audio data stored in the buffer varies over time based at least in part on packet scheduling associated with a wireless communication protocol.

[0021] In some examples, the wireless communication protocol is the BLUETOOTH® protocol.

[0022] In some instances, a reconstructed version of the audio frame containing the corrupted source block is presented through a loudspeaker.

[0023] Some or all of the operations, functions, and / or methods described herein may be performed by one or more devices according to instructions (e.g., software) stored on one or more non-transitory media. Such non-transitory media may include memory devices such as those described herein, including, but not limited to, random access memory (RAM) devices, read-only memory (ROM) devices, etc. Thus, some innovative aspects of the subject matter described in this disclosure may be implemented via one or more non-transitory media having software stored thereon.

[0024] At least some aspects of the present disclosure may be implemented via an apparatus. For example, one or more devices may be capable of at least partially performing the methods disclosed herein. In some implementations, the apparatus is or includes an audio processing system having an interface system and a control system. The control system may include one or more general-purpose single- or multi-chip processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or a combination thereof.

[0025] The details of one or more implementations of the subject matter described herein are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages will become apparent from the description, drawings, and claims. It should be noted that the relative dimensions of the following figures may not be drawn to scale. [Brief explanation of the drawings]

[0026] [Figure 1] 1 is a schematic diagram of an exemplary system for wireless audio stream transmission, according to some embodiments.

[0027] [Figure 2]1 is a flowchart of an exemplary process for transmitting an audio stream, according to some embodiments.

[0028] [Figure 3] 1 is a schematic diagram of an exemplary packet for transmitting an audio stream, according to some embodiments.

[0029] [Figure 4] 1 is a flowchart of an exemplary process for receiving and presenting an audio stream, according to some embodiments.

[0030] [Figure 5] 10 illustrates exemplary data showing latency of an audio stream transported utilizing techniques described herein, according to some embodiments.

[0031] [Figure 6] FIG. 1 shows a block diagram illustrating example components of an apparatus capable of implementing various aspects of the present disclosure.

[0032] Like reference numbers and designations in the various drawings indicate like elements. DETAILED DESCRIPTION OF THE INVENTION

[0033] Unreliability in transmitting audio streams over wireless communication links, such as BLUETOOTH® and WiFi, can lead to dropped or corrupted packets. Generally, dropped or corrupted packets can result in the retransmission of an entire frame of audio data. Frame retransmissions can lead to latency issues, for example, by pausing audio playback while waiting for the frame to be retransmitted. This can be particularly problematic during playback of audio content that includes real-time audio (e.g., telephone or teleconference conversations) and / or audio content synchronized with video content. Furthermore, retransmitting an entire frame when only portions of the frame may be corrupted or dropped (e.g., if the frame is split into multiple packets and only a subset of the packets is dropped or corrupted) is an inefficient use of the wireless channel.

[0034] Described herein are systems, methods, and media for wireless audio stream transmission. The techniques described herein allow wireless channel capacity to be utilized more efficiently. In particular, the techniques described herein utilize forward error correction to reconstruct portions of dropped or corrupted frames, thereby reducing the need to retransmit dropped or corrupted frames. Furthermore, the techniques described herein may reduce playback latency and reduce latency variance, thereby reducing the number of pauses in audio content playback.

[0035] In some implementations, a transmitting device, which may include an encoder, may divide a frame of an audio signal into source blocks. The transmitting device may then generate a set of parity blocks from which corrupted or dropped source blocks may be reconstructed. In particular, each block may contain a mathematically hashed version of the audio data for that block. The transmitting device may then transmit the source blocks and the parity blocks to a receiving device. The receiving device, which may include a decoder, may determine whether any of the source blocks are dropped or corrupted and, if so, may use the parity blocks to reconstruct the dropped or corrupted source blocks.

[0036] In some embodiments, the number of source blocks and / or the number of parity blocks may be selected to optimize channel capacity for a wireless communication protocol. For example, the number of parity blocks may be selected to be the maximum number of blocks that can be transmitted according to the packet size and packet scheduling constraints specified by the wireless communication protocol, thereby maximizing the number of source blocks that can be reconstructed. More detailed techniques for determining the number of source blocks and / or the number of parity blocks are shown in and described below in connection with FIG. 2. Furthermore, the total number of blocks generated and transmitted per frame may be varied in a manner that optimizes channel capacity by allowing additional parity blocks to be transmitted per frame, as shown and described in more detail below in connection with FIGs. 2 and 3.

[0037] It should be noted that a variety of forward error correction techniques or algorithms may be utilized in conjunction with the techniques described herein. Examples include Reed-Solomon encoding, Hamming encoding, binary convolutional encoding, low-density parity-check encoding, etc. Forward error correction techniques are further described in "Forward Error Correction Techniques for Digital Signal Processors," by "Digital Signal Processors," IEEE Transactions on Information Processing, Vol. 1, No. 1, pp. 111-114, 2003, which is incorporated herein by reference in its entirety. [Non-Patent Document 1] Watson, M., Begen, A., and Roca, V. Forward Error Correction (FEC) Framework RFC 6363, 2011

[0038] 1 illustrates an example of a system 100 for compressed audio transport according to some embodiments. As shown, the system 100 includes a transmitting device 102 that packetizes audio frames and transmits the packets, and a receiving device 104 that receives the packets and reconstructs the audio frames based on the received packets.

[0039] In some embodiments, the encoder 108 of the transmitting device 102 may obtain the input audio frame 106. In some embodiments, the input audio frame 106 may have any suitable duration (e.g., 10 milliseconds, 32 milliseconds, 40 milliseconds, etc.). In some embodiments, the encoder 108 may obtain the input audio frame 106 in any suitable manner, such as by retrieving the input audio frame 106 from a memory that stores the audio stream, by identifying the next audio frame in the audio stream, etc.

[0040] In some embodiments, the encoder 108 may divide the input audio frame 106 into a set of blocks. The set of blocks may include a set of source blocks 110. Note that the set of source blocks is generally represented herein as having K source blocks. The set of blocks may further include a set of parity blocks 112. Note that the set of parity blocks is generally represented herein as having P parity blocks. As shown in FIG. 1, the set of blocks is generally represented as having N blocks, where N is represented by K+P (e.g., the number of source blocks + the number of parity blocks). In some embodiments, the number of source blocks and the number of parity blocks may depend on characteristics of the wireless transmission protocol used by the transmitting device 102 and the receiving device 104, as shown and described in more detail below in connection with FIG. 2.

[0041] In some embodiments, the transmitter 114 may transmit the set of source blocks 110 and the set of parity blocks 112. For example, the transmitter 114 may wirelessly transmit data represented by the set of source blocks 110 and the set of parity blocks 112 using one or more antennas. In some embodiments, the transmitter 114 may transmit the set of source blocks 110 and the set of parity blocks 112 as a sequence of packets 116, with each packet in the sequence of packets 116 corresponding to a block in the set of source blocks 110 or the set of parity blocks 112. In some embodiments, the transmitter 114 may transmit the sequence of packets 116 in accordance with a scheduling protocol or scheduling constraints specified by or associated with a wireless communication protocol utilized by the transmitter 114.

[0042] With reference to the receiving device 104, the receiver 118 of the receiving device 104 may receive the sequence of packets 120. For example, the receiver 118 may utilize one or more antennas to wirelessly receive packets of the sequence of packets 116 transmitted by the transmitter 114. As shown in FIG. 1, in some embodiments, the received sequence of packets 120 may include a subset of packets transmitted by the transmitter 114 of the transmitting device 102. For example, in the example shown in FIG. 2, two packets corresponding to two source blocks were dropped during transmission, such that packets "5" and "K" are missing from the received sequence of packets 120. Note that the received sequence of packets 120 is shown by way of example only. In some instances, one or more packets may include corrupted blocks, or the dropped packets may correspond to parity blocks. In other words, the received sequence of packets 120 may differ in any suitable manner from the transmitted sequence of packets 116. Alternatively, in some cases, the received sequence of packets 120 may perfectly correspond to the transmitted sequence of packets 116, indicating a complete, uncorrupted transmission of the input audio frame 106. In such cases, forward error correction utilizing the received parity blocks is not required.

[0043] The decoder 122 of the receiving device 104 may generate a reconstructed audio frame 124. For example, in some implementations, the decoder 122 may utilize a forward error correction technique, such as Reed-Solomon encoding, Hamming encoding, or the like, to reconstruct dropped and / or corrupted source blocks of the received sequence of packets 120 using parity blocks included in the sequence of packets 120, as shown and described below in connection with FIG.

[0044] In some implementations, the reconstructed audio frames 124 may then be rendered and / or played back. For example, in some embodiments, the reconstructed audio frames 124 may be rendered using various algorithms for distributing one or more audio signals across speakers and / or headphones to achieve a particular perceptual impression (e.g., reflecting spatial characteristics of the audio stream specified by a content creator). As another example, in some embodiments, the reconstructed audio frames 124 may be played back, such as by presenting the reconstructed audio frames 124 through one or more loudspeakers, headphones, etc. In some implementations, the reconstructed audio frames 124 may be presented in a manner that is substantially synchronized with the presentation of the video content.

[0045] It should be noted that in some implementations, packets corresponding to a compressed audio stream may be transmitted in a unicast network topology, in which one transmitting device transmits packets to be received by one receiving device, or in a multicast network topology, in which one transmitting device transmits packets to many receiving devices (e.g., two, three, five, ten, twenty, etc.).

[0046] In some embodiments, an encoder (e.g., of a transmitting device) may determine the number of source blocks and the number of parity blocks to be generated in association with a frame of an audio signal. In some implementations, the number of source blocks and the number of parity blocks may be determined to optimize use of wireless communication protocol channel capacity. For example, the selected number of source blocks and the number of parity blocks may be such that a certain amount of corrupted or dropped source blocks can be reconstructed using the parity blocks, such that the reconstruction results in few or no frames needing to be replaced with dummy frames or retransmitted. In one example, the number of source blocks and the number of parity blocks may be selected such that up to 30% of the source blocks for a given frame can be reconstructed. In some implementations, the number of source blocks and / or the number of parity blocks may be selected based on timing information associated with the wireless communication protocol used to transmit the audio stream. In some implementations, the timing information may include packet scheduling constraints associated with the wireless communication protocol. In some embodiments, the number of source blocks and / or the number of parity blocks may be determined based on the frame size of the frames of the audio signal and / or the packet size of the packets to be used to transmit the blocks. A more detailed technique for selecting the number of source blocks and / or the number of parity blocks in a manner that optimizes channel capacity is shown in and described below in connection with FIG. 2.

[0047] FIG. 2 shows an example of a process 200 for transmitting a compressed audio stream, according to some embodiments. The blocks of process 200 may, in some examples, be performed by a control system, such as control system 610 of FIG. 6 . According to some examples, the blocks of process 200 may be performed by a transmitting device, such as transmitting device 102 shown in FIG. 1 . In some implementations, the blocks of process 200 may be performed by an encoder and / or transmitter of the transmitting device. In some embodiments, the blocks of process 200 may be performed in an order other than that shown in FIG. 2 . In some implementations, two or more blocks of process 200 may be performed substantially in parallel. In some embodiments, one or more blocks of process 200 may be omitted.

[0048] Process 200 may begin by obtaining a frame of an audio signal at 202. For example, in some implementations, process 200 may obtain the frame from a memory or other storage location. As another example, in some embodiments, process 200 may identify a frame as the next or subsequent frame of the audio signal to be transmitted.

[0049] At 204, process 200 can identify, based at least in part on characteristics of the wireless communication protocol to be used, a number of source blocks (generally represented herein as K) into which to divide a frame of the audio signal and a number of parity blocks (generally represented herein as P) to generate for forward error correction.

[0050] In some implementations, the number of source blocks and / or the number of parity blocks may be determined based on timing information. In some embodiments, the timing information may include packet scheduling specifications or constraints associated with a wireless communication protocol. In some embodiments, the total number of blocks (e.g., source blocks plus parity blocks) N may be determined based on the timing information. For example, in some embodiments, N may be determined as the number of blocks that may be transmitted given a particular packet scheduling (e.g., a timing interval in which packets are transmitted by a transmitter) associated with a wireless communication protocol within the duration of a frame. By way of example, N may be N=(frame_duration) / (packet_interval) [N = (frame duration) / (packet interval)] can be determined by

[0051] In the above equation, "frame_duration" represents a time interval corresponding to a frame (e.g., in milliseconds or any other suitable units), and "packet_interval" represents a timing interval during which packets are transmitted (e.g., the number of milliseconds between successively transmitted packets). In some implementations, the number of source blocks (e.g., K) may be determined based on the size (e.g., in bytes) of a frame of the audio signal and the size (e.g., in bytes) of a packet associated with a wireless communication system. For example, the number of source blocks may be determined as the number of blocks required to divide a frame having a particular frame size into a set of packets, each packet having the packet size. As an example, K may be determined using the following equation: K=(frame_size) / (packet_size) [K = (frame size) / (packet size)] can be determined by

[0052] In the above equation, "frame_size" represents the size of an audio frame (e.g., in bytes or any other suitable units), and "packet_size" represents the size of the packet to be transmitted (e.g., in bytes or any other suitable units). In some implementations, the number of parity blocks (e.g., P) may be determined as the difference between the total number of blocks and the number of source blocks. For example, P may be: P=NK It may be determined by:

[0053] The following are examples for determining the total number of blocks, the number of source blocks, and the number of parity blocks for different audio stream bit rates and different wireless communication protocols. In some embodiments, the wireless communication protocol may transmit audio packets at a predetermined packet size and using a predetermined packet scheduling interval. In some implementations, the wireless communication protocol may be one that allows the transmission of uncompressed audio, and whose available bandwidth can also be used to reliably transport compressed audio. For example, in some implementations, packets may contain compressed audio data using, for example, 24-bit (or 16-bit, etc.) pulse-coded modulation (PCM). The examples shown below assume a frame duration of 32 milliseconds. However, this is merely an example, and the techniques described herein may be applied to frames having different durations. Furthermore, the techniques described herein may be applied to wireless communication protocols utilizing various audio stream bit rates, other packet sizes and / or packet scheduling specifications, and / or other wireless communication protocols (e.g., WiFi) beyond those described in the examples below.

[0054] The following table shows the frame sizes (in bytes) that can be used for audio streams with various bit rates (in kbps). The frame size can be used to determine the number of source blocks. [Table 1]

[0055] In a first example, the wireless communication link may transport audio packets, each having a packet size of 288 bytes and a packet scheduling interval of one packet per millisecond. In this example, the packets may be transmitted using a packet scheduling interval of one packet per millisecond. Thus, for a frame size of 3072 bytes (corresponding to a bit rate of 768 kbps), the total number of blocks N may be determined as the frame duration (32 milliseconds) divided by the packet interval (1 millisecond). That is, in this case, N may be a total of 32 blocks. Continuing with this first example, the number of source blocks K may be determined as the frame size (3072 bytes) divided by the packet size (288 bytes). That is, in such a case, K may be 10.67, or rounded up to 11 source blocks. Correspondingly, the number of parity blocks P may be 32 - 11, or 19 parity blocks.

[0056] In a second example utilizing a packet size of 288 bytes and a packet scheduling interval of 1 packet per millisecond, for a frame size of 5426 bytes (corresponding to a bit rate of 1355 kbps), the total number of blocks N may be determined as the frame duration (32 milliseconds) divided by the packet interval (1 millisecond). That is, N may be a total of 32 blocks. Continuing with this second example, the number of source blocks K may be determined as the frame size (5426 bytes) divided by the packet size (288 bytes). That is, in such a case, K may be 18.82, or rounded up to 19 source blocks. Note that in some implementations, a partial portion of the last source block may be used to encode bytes of the next frame. In some such implementations, these extra bytes may be used to correct any corruption in the first source block of the next frame. Additionally or alternatively, some implementations may use a copy of the first bytes of the frame. Correspondingly, the number of parity blocks P may be 32, 19, or 11 parity blocks. In some implementations, such as in some cases where the frame duration is an integer number of milliseconds, the total number of blocks used for a frame of an audio signal may be the same regardless of the bit rate and / or frame size (e.g., a total of 32 blocks per frame). In other implementations, the total number of blocks used for a frame of an audio signal may depend on the packet scheduling interval rather than the bit rate and / or frame size. In other implementations, the total number of blocks per frame may vary based on the bit rate and / or frame size.

[0057] In an example where BLUETOOTH® is used as the wireless communication protocol, packets may have a size of up to 240 bytes (e.g., 200 bytes, 224 bytes, 230 bytes, 236 bytes, 240 bytes, etc.). BLUETOOTH packets may be transmitted using a packet scheduling interval that is a multiple of 1.25 milliseconds. For example, BLUETOOTH packets may be scheduled to be transmitted in 1.25 millisecond slots, 2.5 millisecond slots, etc. In a first example, for a frame size of 1792 bytes (corresponding to a bit rate of 448 kbps), a packet size of 224 bytes, and a packet scheduling interval of 2.5 milliseconds, the total number of blocks, N, may be determined as the frame duration (32 milliseconds) divided by the packet scheduling interval (2.5 milliseconds). That is, in such a case, N may be 12.8, or rounded up to a total of 13 blocks. Continuing with this first example, the number of source blocks, K, may be determined as the frame size (1792 bytes) divided by the packet size (224 bytes). That is, in such a case, K may be 8 source blocks. Correspondingly, the number of parity blocks, P, may be 13 - 8, or 5 parity blocks.

[0058] It should be noted that in some implementations, the number of parity blocks may effectively depend on the bit rate of the audio signal. For example, because the number of source blocks is proportional to the frame size, which in turn is proportional to the bit rate, for a fixed total number of blocks, the number of parity blocks may be inversely proportional to the bit rate. In other words, more parity blocks may be used for lower bit rate signals than for higher bit rate signals. It should be noted that in some implementations, the bit rate may be adapted to balance the trade-off between audio quality and forward error correction implementation. As an example, in some embodiments, the receiver device may send a message to the transmitter device that the quality of the received audio signal is degraded. Continuing with this example, the transmitter may select a lower bit rate for transmitting the audio signal, which may result in lower audio quality, but there is additional headroom for transmitting parity blocks, which may be utilized by the receiver device for forward error correction.

[0059] 2, at 206, process 200 may subdivide the frame into K source blocks. The frame subdivision may be by dividing the frame's data into the K blocks such that the frame's data is generally evenly divided among the K source blocks.

[0060] At 208, process 200 may generate P parity blocks using the K source blocks. For example, in some implementations, process 200 may use a particular forward error correction technique or algorithm to generate P parity blocks using the K source blocks. Examples of forward error correction techniques that may be used include Reed-Solomon encoding, Hamming encoding, etc. In an example where Reed-Solomon encoding is used and N=32, K=19, and P=11, a (32,19) Reed-Solomon scheme may be used. Similarly, in an example where Reed-Solomon encoding is used and N=13, K=8, and P=5, a (13,8) Reed-Solomon scheme may be used. It should be understood that other forward error correction techniques, such as Hamming codes, binary convolutional codes, low-density parity-check codes, etc., may also be used. In some implementations, the forward error correction technique used may be selected based on the correction efficiency of the technique and / or any other considerations.

[0061] At 210, process 200 may transmit the K source blocks and P parity blocks using a wireless communication protocol. For example, in some implementations, the source blocks and parity blocks may be transmitted as a sequence of packets, where each packet is transmitted according to a packet scheduling constraint associated with the wireless communication protocol. For example, for some communication protocols, the sequence of packets may be transmitted as one packet per millisecond. As another example, if the wireless communication protocol is BLUETOOTH®, the sequence of packets may be transmitted as one packet per 2.5 milliseconds (or any other suitable multiple of 1.25 milliseconds).

[0062] Note that in some implementations, a header may be added to the packet. For example, the header may indicate the forward error correction scheme (e.g., utilized in block 208) for generating the parity blocks. As a more specific example, the header may indicate the type of algorithm used, the total number of blocks, the number of source blocks, and / or the number of parity blocks. As another example, in some embodiments, the header may include a checksum, such as a cyclic redundancy check (CRC), that may be utilized to determine whether the packet is corrupted. As yet another example, in some embodiments, the header may include a sequence counter that may be utilized to detect dropped packets.

[0063] Process 200 may then loop back to block 202 to obtain another frame of the audio signal. Process 200 may loop through blocks 202-210 until the entire audio signal has been transmitted. Additionally or alternatively, in some implementations, process 200 may loop through blocks 202-210 until a command to stop transmitting the audio signal is received (e.g., a signal received from a user device, from a remote control device, from a keyboard or other user input device, a spoken signal, a gesture associated with a command to stop transmitting the audio signal, etc.).

[0064] Note that the transmission of parity blocks may increase the overall transmission bit rate associated with the audio stream. In one example, an audio stream transmitted at 448 kbps without parity blocks may be transmitted at a bit rate of 653 kbps due to the extra data associated with the parity blocks. However, using parity blocks to reconstruct dropped or corrupted source blocks (using forward error correction) reduces or completely eliminates retransmitted frames, thereby improving the overall efficiency of the wireless channel.

[0065] In some implementations, the total number of blocks used to encode a frame may vary from frame to frame.

[0066] In some embodiments, the number of parity blocks may vary from frame to frame based on the total number of blocks utilized. For example, the total number of blocks utilized may vary, but the number of source blocks may remain fixed from frame to frame. Thus, the number of parity blocks may vary from frame to frame, e.g., to account for a varying total number of blocks with a fixed number of source blocks. In some implementations, the frame-to-frame variation may occur in a repeatable manner that depends on timing information (e.g., packet scheduling constraints) associated with a particular wireless communication protocol.

[0067] For example, in a case where BLUETOOTH® is used as the wireless communication protocol, packets (each corresponding to a block) may be transmitted at time intervals of 2.5 milliseconds (or any other suitable multiple of 1.25 milliseconds). Thus, in a case where a frame is subdivided into nine source blocks, the first frame may be associated with four parity blocks for a total of 13 blocks. Because the 13 blocks (corresponding to one frame of the audio signal) are transmitted in 32.5 milliseconds (e.g., 13 x 2.5 milliseconds), which is longer than the 32 millisecond duration of the frame, the transmitting device may effectively be running behind the audio stream. Thus, after a certain number of frames, the total number of blocks may be reduced (e.g., reduced by 1) to account for the extra time required to transmit blocks for preceding frames. As an example, four frames with a total of 13 blocks (e.g., nine source blocks and four parity blocks) may be transmitted, followed by a fifth frame with a total of 12 blocks (e.g., nine source blocks and three parity blocks). Note that in this example, using a scheme of 13 blocks for the first four frames and 12 blocks for the fifth frame, a total of 64 blocks may be transmitted (e.g., each as a packet) across five frames. This spans 160 ms (e.g., 64 x 2.5 ms), which corresponds to a duration spanning five frames (e.g., 32 ms x 5).

[0068] FIG. 3 illustrates an exemplary packetization scheme in which the number of blocks utilized per frame varies by frame, according to some embodiments. As illustrated, for Frame 1, nine source blocks and four parity blocks are transmitted. These blocks are grouped into groups of four, and each block is transmitted in association with a packet, with the packets transmitted 2.5 milliseconds apart. Thus, four blocks (source or parity) are transmitted in 10 milliseconds. Similarly, Frames 2, 3, and 4 are associated with nine source blocks and four parity blocks. However, due to the extra time required to transmit 13 blocks per frame, for Frame 5, nine source blocks and three parity blocks (e.g., one less parity block) are transmitted, allowing the encoding scheme to realign with the frames of the audio signal.

[0069] In some implementations, a receiving device (e.g., a Bluetooth or Wi-Fi connected speaker or headphones) may receive a sequence of packets, each packet corresponding to a transmitted block (e.g., a source block or a parity block). In some embodiments, a decoder of the receiving device may determine the number of corrupted or dropped blocks among the set of source blocks associated with the received sequence of packets. In some implementations, in response to determining that at least one source block is corrupted or dropped during transmission, the decoder may determine whether the corrupted or dropped blocks can be reconstructed using the parity blocks. For example, the decoder may determine whether the number of corrupted blocks is less than the number of parity blocks. In some embodiments, in response to determining that the corrupted blocks can be reconstructed, the decoder may reconstruct the corrupted blocks and present an audio frame including the reconstructed source blocks. Conversely, in response to determining that the corrupted blocks cannot be reconstructed, the decoder may generate a substitute frame or a "dummy" frame and present the substitute frame or the dummy frame.

[0070] FIG. 4 shows an example of a process 400 for reconstructing source blocks and presenting an audio signal, according to some embodiments. The blocks of process 400 may, in some examples, be performed by a control system, such as control system 610 of FIG. 6. In some embodiments, the blocks of process 400 may be performed on a receiving device, such as receiving device 104 of FIG. 1. In some embodiments, the blocks of process 400 may be performed by a decoder and / or receiver of the receiving device. In some implementations, the blocks of process 400 may be performed in an order other than that shown in FIG. 4. In some embodiments, two or more blocks of process 400 may be performed substantially in parallel. In some embodiments, one or more blocks of process 400 may be omitted.

[0071] Process 400 may begin at 402 by receiving a set of source blocks and a set of parity blocks corresponding to a frame of an audio signal. In some embodiments, each block may be associated with a received packet in a sequence of received packets. In some implementations, process 400 may obtain a block (e.g., a source block or a parity block) from a packet. In some implementations, process 400 may obtain a block using information stored in a header of the packet.

[0072] At 404, process 400 may determine the number of corrupted or dropped source blocks among the set of source blocks. In some implementations, process 400 may identify a source block among the set of source blocks as corrupted based at least in part on a checksum (e.g., a CRC value) included in the header of the packet corresponding to the source block. Corrupted source blocks may be identified using any suitable forward error correction technique, such as using Reed-Solomon encoding. In some implementations, process 400 may identify the number of dropped source blocks by identifying the difference between the expected number of source blocks (e.g., as specified by the forward error correction scheme being used) and the received number of source blocks.

[0073] At 406, process 400 may determine whether the number of corrupted or dropped source blocks is zero. If at 406 process 400 determines that the number of corrupted or dropped source blocks is zero (“yes” at 406), process 400 may proceed to 408, where an audio frame may be generated using the set of source blocks. For example, process 400 may reconstruct a full-length audio frame using data contained in source blocks of the set of source blocks. Process 400 may then proceed to block 414, where the audio frame may be presented (e.g., via one or more speakers, one or more headphones, etc.).

[0074] Conversely, if process 400 determines at 406 that the number of corrupted or dropped blocks is not zero (“no” at 406), process 400 may proceed to block 410 and determine whether the number of corrupted or dropped source blocks is less than or equal to the number of parity blocks. For example, if the number of received parity blocks is three, process 400 may determine that the number of corrupted or dropped blocks is less than or equal to the number of parity blocks if the number of corrupted or dropped blocks is one, two, or three. Note that at 402, the number of received parity blocks may be less than the number of parity blocks transmitted by the transmitting device (e.g., in cases where parity blocks are dropped). Thus, in some embodiments, process 400 may compare the number of corrupted or dropped source blocks to the number of received parity blocks (e.g., rather than the number of expected or transmitted parity blocks). Additionally or alternatively, in some implementations, one or more of the received parity blocks may be corrupted. Thus, in some implementations, process 400 may compare the number of corrupted or dropped source blocks to the number of uncorrupted received parity blocks (e.g., parity blocks that may be used in forward error correction).

[0075] If process 400 determines at 410 that the number of corrupted or dropped source blocks is less than or equal to the number of parity blocks (“yes” at 410), process 400 may proceed to 412, where an audio frame may be generated by reconstructing the corrupted or dropped source blocks. For example, process 400 may use a forward error correction scheme to reconstruct the corrupted or dropped source blocks using the received parity blocks. As described above, the forward error correction scheme (e.g., Reed-Solomon encoding, Hamming encoding, etc.) used to generate the parity blocks may similarly be used to reconstruct the corrupted or dropped source blocks. In some implementations, the forward error correction scheme to be used may be specified in one or more packet headers of the packets corresponding to the received source blocks and the received parity blocks (e.g., as described above with respect to block 402).

[0076] Conversely, if at 410 process 400 determines that the number of corrupted or dropped source blocks exceeds the number of parity blocks (“no” at 410), process 400 may proceed to 414, where a replacement or dummy audio frame may be generated. In some embodiments, the replacement or dummy audio frame may soft-mute the decoder output by, for example, lowering the overall sound level for the duration of the audio frame presentation. In some implementations, audio data from a preceding frame and / or a next frame may be utilized to generate the replacement frame. For example, in some implementations, interpolation may be used to generate data corresponding to the replacement frame. In one example, interpolation may be performed between audio data from a previous frame and audio data of a next frame.

[0077] Regardless of whether block 412 or 414 is performed, at 416, process 400 may present the audio frame. For example, process 400 may present the audio frame (either the audio frame including the reconstructed corrupted or dropped source block or the replacement / dummy audio frame) through one or more speakers, one or more headphones, etc. Note that before presenting the audio frame, in some embodiments, process 400 may render the audio frame to create a particular perceptual impression, for example, by routing the audio signal to one or more speakers, headphones, etc.

[0078] In some implementations, the techniques described above may generate a number of source blocks and a number of parity blocks optimized for the channel capacity of a particular type of wireless link. More specifically, the number of source blocks and the number of parity blocks may be selected (using the techniques described herein) so that a relatively small number of frames need to be retransmitted or replaced with dummy frames due to not having enough parity blocks to reconstruct corrupted or dropped source blocks. Furthermore, by determining the number of source blocks and the number of parity blocks based on packet scheduling constraints, the techniques described herein may allow a buffer associated with a decoder (e.g., in a receiving device) to generally maintain a non-zero amount of data or a non-zero duration of audio data, thereby reducing overall system latency. For example, in cases where the total number of blocks (e.g., source blocks and parity blocks) associated with a frame are transmitted for a duration that exceeds the duration of the frame, there may be an initial latency at the decoder to receive all of the blocks corresponding to the frame. However, because of the initial latency, the decoder may be able to maintain a buffer that thereafter generally remains at about 0 milliseconds. This can allow the receiving device to continuously play the audio stream without pauses or interruptions to allow the buffer to catch up, which may be particularly advantageous in cases where real-time audio data is being presented and / or where audio content is being presented that is synchronized with video content.

[0079] Figure 5 illustrates an example of buffer latency utilizing the source and parity block scheme shown and described above in connection with Figure 3. Figure 3 described an exemplary source and parity block scheme associated with Bluetooth communications in which packets (each corresponding to a block) are transmitted at 2.5 millisecond intervals, with four blocks transmitted per 10 millisecond isochronous interval. In the example shown in Figure 3 and described above, for the first four frames, nine source blocks and four parity blocks are transmitted, and for the fifth frame, nine source blocks and three parity blocks are transmitted.

[0080] Referring to FIG. 5, curve 502 illustrates the duration, in milliseconds, of audio data stored in the decoder's buffer. Each step on curve 502 corresponds to blocks received at 10-millisecond isochronous intervals (e.g., four blocks received at 2.5-millisecond packet spacing intervals). For the first four frames, 13 blocks are utilized, so the decoder receives all of the audio data for the frame (having a duration of 32 milliseconds) in 40 milliseconds (e.g., four isochronous intervals). In other words, the 13th block is received during the fourth isochronous interval, which spans 30 to 40 milliseconds, so the decoder is ready to present the first audio frame 40 milliseconds later. Thus, as illustrated by curve 502 in FIG. 5, after 40 milliseconds, one frame's worth of audio data (e.g., 32 milliseconds) is presented, so the duration of the audio data stored in the buffer drops from 40 milliseconds to 8 milliseconds. Curve 504 shows the duration of unplayed audio data stored in the buffer. As shown, due to the discrepancy between the duration required to receive a 32-millisecond frame of audio data versus the duration of an audio frame, the buffer always has at least partial data for the next frame. Furthermore, due to forward error correction (e.g., parity blocks), the data in the buffer can generally correspond to usable source blocks (e.g., usable as is and / or can be reconstructed using parity blocks), thereby allowing for more robust audio playback. This may allow the decoder to allow continuous or near-continuous audio playback without requiring pauses to allow time for additional data to be buffered.

[0081] FIG. 6 is a block diagram illustrating example components of a device capable of implementing various aspects of the present disclosure. As with other figures provided herein, the types and number of elements shown in FIG. 6 are provided merely as examples. Other implementations may include more, fewer, and / or different types and numbers of elements. According to some examples, device 600 may be configured to perform at least some of the methods disclosed herein. In some implementations, device 600 may be or include a television, one or more components of an audio system, a mobile device (such as a cellular phone), a laptop computer, a tablet device, a smart speaker, or another type of device.

[0082] According to some alternative implementations, apparatus 600 may be or include a server. In some such examples, apparatus 600 may be or include an encoder. Thus, in some instances, apparatus 600 may be a device configured for use in an audio environment, such as a home audio environment, while in other instances, apparatus 600 may be a device configured for use in the “cloud,” e.g., a server.

[0083] In this example, device 600 includes an interface system 605 and a control system 610. Interface system 605, in some implementations, may be configured to communicate with one or more other devices in an audio environment. The audio environment, in some examples, may be a home audio environment. In other examples, the audio environment may be another type of environment, such as an office environment, an automobile environment, a train environment, a street or sidewalk environment, a park environment, etc. Interface system 605, in some implementations, may be configured to exchange control information and associated data with audio devices in the audio environment. The control information and associated data, in some examples, may relate to one or more software applications running on device 600.

[0084] The interface system 605, in some implementations, may be configured to receive or provide a content stream. The content stream may include audio data. The audio data may include, but is not limited to, an audio signal. In some instances, the audio data may include spatial data, such as channel data and / or spatial metadata. In some examples, the content stream may include video data and audio data corresponding to the video data.

[0085] The interface system 605 may include one or more network interfaces and / or one or more external device interfaces (e.g., one or more universal serial bus (USB) interfaces). According to some implementations, the interface system 605 may include one or more wireless interfaces. The interface system 605 may include one or more devices for implementing a user interface, such as one or more microphones, one or more speakers, a display system, a touch sensor system, and / or a gesture sensor system. In some examples, the interface system 605 may include one or more interfaces between the control system 610 and a memory system, such as the optional memory system 615 shown in FIG. 6 . However, the control system 610 may include a memory system in some cases. In some implementations, the interface system 605 may be configured to receive input from one or more microphones in the environment.

[0086] The control system 610 may include, for example, a general-purpose single or multi-chip processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, and / or discrete hardware components.

[0087] In some implementations, the control system 610 may reside in more than one device. For example, in some implementations, a portion of the control system 610 may reside in a device within one of the environments described herein, while another portion of the control system 610 may reside in a device outside of the environment, such as a server, a mobile device (e.g., a smartphone or tablet computer), or the like. In other examples, a portion of the control system 610 may reside in a device within one environment, while another portion of the control system 610 may reside in one or more other devices within the environment. For example, a portion of the control system 610 may reside in a device implementing a cloud-based service, such as a server, while another portion of the control system 610 may reside in another device implementing the cloud-based service, such as another server, memory device, or the like. The interface system 605 may also reside in more than one device, in some examples.

[0088] In some implementations, the control system 610 may be configured to at least partially perform the methods disclosed herein. According to some examples, the control system 610 may be configured to implement methods such as determining the number of source blocks and / or parity blocks for a particular wireless communication protocol, generating one or more parity blocks, transmitting and / or receiving packets, reconstructing corrupted source blocks, presenting reconstructed audio frames, etc.

[0089] Some or all of the methods described herein may be performed by one or more devices according to instructions (e.g., software) stored on one or more non-transitory media. Such non-transitory media may include memory devices such as those described herein, including, but not limited to, random access memory (RAM) devices, read-only memory (ROM) devices, etc. The one or more non-transitory media may reside, for example, in optional memory system 615 and / or control system 610 shown in FIG. 6. Thus, various innovative aspects of the subject matter described in this disclosure may be implemented in one or more non-transitory media storing software. The software may include, for example, instructions for determining the number of source blocks and / or parity blocks for a particular wireless communication protocol, generating one or more parity blocks, transmitting and / or receiving packets, reconstructing corrupted source blocks, presenting reconstructed audio frames, etc. The software may be executable by one or more components of a control system, such as control system 610 of FIG. 6.

[0090] In some examples, device 600 may include the optional microphone system 620 shown in FIG. 6 . The optional microphone system 620 may include one or more microphones. In some implementations, one or more of the microphones may be part of or associated with another device, such as a speaker of a speaker system, a smart audio device, or the like. In some examples, device 600 may not include microphone system 620. However, in some such implementations, device 600 may still be configured to receive microphone data for one or more microphones in the audio environment via interface system 610. In some such implementations, a cloud-based implementation of device 600 may be configured to receive microphone data, or noise metrics corresponding at least in part to the microphone data, from one or more microphones in the audio environment via interface system 610.

[0091] According to some implementations, device 600 may include an optional loudspeaker system 625 shown in FIG. 6. Optional loudspeaker system 625 may include one or more loudspeakers, which may also be referred to herein as a "speaker" or, more generally, an "audio reproduction transducer." In some examples (e.g., cloud-based implementations), device 600 may not include loudspeaker system 625. In some implementations, device 600 may include headphones. The headphones may be connected or coupled to device 600 via a headphone jack or via a wireless connection (e.g., BLUETOOTH®).

[0092] Some aspects of the present disclosure include systems or devices configured (e.g., programmed) to perform one or more examples of the disclosed methods, and tangible computer-readable media (e.g., disks) storing code for implementing one or more examples of the disclosed methods or steps thereof. For example, some disclosed systems may be or include a programmable general-purpose processor, digital signal processor, or microprocessor programmed with software or firmware and / or configured to perform any of various operations on data, including embodiments of the disclosed methods or steps thereof. Such a general-purpose processor may be or include a computer system that includes an input device, a memory, and a processing subsystem programmed (and / or otherwise configured) to perform one or more examples of the disclosed methods (or steps thereof) in response to asserted data.

[0093] Some embodiments may be implemented as a configurable (e.g., programmable) digital signal processor (DSP) configured (e.g., programmed and otherwise configured) to perform necessary processing on audio signal(s), including performing one or more examples of the disclosed methods. Alternatively, embodiments of the disclosed system (or elements thereof) may be implemented as a general-purpose processor (e.g., a personal computer (PC) or other computer system or microprocessor, which may include input devices and memory) that is programmed with software or firmware and / or otherwise configured to perform any of a variety of operations, including one or more examples of the disclosed methods. Alternatively, elements of some embodiments of the inventive system are implemented as a general-purpose processor or DSP configured (e.g., programmed) to perform one or more examples of the disclosed methods, and the system also includes other elements (e.g., one or more loudspeakers and / or one or more microphones). A general-purpose processor configured to perform one or more examples of the disclosed methods may be coupled to an input device (e.g., a mouse and / or keyboard), memory, and a display device.

[0094] Another aspect of the present disclosure is a computer-readable medium (e.g., a disk or other tangible storage medium) that stores code (e.g., executable code) for performing one or more examples of the disclosed methods or steps thereof.

[0095] While particular embodiments of the present disclosure and applications of the present disclosure have been described herein, it will be apparent to those skilled in the art that many variations on the embodiments and applications described herein are possible without departing from the scope of the present disclosure as described and claimed herein. While certain forms of the present disclosure have been illustrated and described, it should be understood that the present disclosure should not be limited to the specific embodiments described and illustrated, or to the specific methods described.

[0096] Several aspects will be described. [Aspect 1] A method for transmitting an audio stream, comprising: acquiring frames of an audio signal; determining a number of source blocks into which to divide a frame of the audio signal and a number of parity blocks to generate for forward error correction, the number of source blocks and the number of parity blocks being determined based at least in part on characteristics of a wireless communication protocol to be used to transmit the audio stream; dividing a frame of the audio signal into the number of source blocks; generating said number of parity blocks using said source blocks; transmitting the source blocks and the parity blocks, the parity blocks being usable by a decoder to reconstruct one or more corrupted or missing source blocks; method. [Aspect 2] 2. The method of claim 1, wherein the parity blocks are generated using a Reed-Solomon encoder. Aspect 3 3. The method of claim 1 or 2, wherein the characteristics of the wireless communication protocol include timing information indicative of packet scheduling of the wireless communication protocol. Aspect 4 The determination of the number of parity blocks is: determining a total number of blocks to be used to encode the frame of the audio signal based on the duration of the frame of the audio signal and the timing information indicative of packet scheduling; determining the number of said source blocks; determining the number of parity blocks by determining the difference between the total number of blocks and the number of source blocks; The method of embodiment 3. Aspect 5 5. The method of any one of aspects 1 to 4, wherein the characteristics of the wireless communication protocol include a frame size of the frames of the audio signal and / or a packet size of packets used to transmit a source block of the source blocks or a parity block of the parity blocks. Aspect 6 6. The method of aspect 5, wherein the number of source blocks to be used is determined by determining a number of packets each having the packet size for transmitting the frame having the frame size. Aspect 7 7. The method of any one of aspects 1 to 6, wherein the number of parity blocks identified for the frame of the audio signal is different from the number of parity blocks generated for a preceding frame of the audio signal. Aspect 8 A method according to any one of aspects 1 to 7, wherein the number of parity blocks generated for frames of the audio signal varies in a repeatable manner determined based on timing information indicative of packet scheduling of the wireless communication protocol. Aspect 9 Aspect 9. The method of any one of aspects 1-8, wherein frames of the audio signal are not retransmitted in response to portions of the frames being dropped or corrupted. Aspect 10 Aspect 10. The method of any one of aspects 1 to 9, wherein the wireless communication protocol is a BLUETOOTH® protocol. Aspect 11 A method for receiving an audio stream, comprising: receiving a set of source blocks and a set of parity blocks corresponding to a frame of an audio signal using a wireless communication protocol, wherein the set of source blocks is at least a subset of the source blocks generated by an encoder, and the set of parity blocks is at least a subset of the parity blocks generated by the encoder, and wherein the number of source blocks and the number of parity blocks generated and transmitted by the encoder are determined at least in part based on characteristics of the wireless communication protocol; determining the number of corrupted source blocks among said set of source blocks; In response to determining that the number of corrupted source blocks is greater than zero, determining whether to reconstruct the corrupted source blocks; reconstructing the corrupted source block in response to determining that the corrupted source block should be reconstructed; and presenting a version of the audio frame including the reconstructed corrupted source block. method. Aspect 12 12. The method of claim 11, wherein determining whether to reconstruct the corrupted source blocks comprises determining whether the number of corrupted source blocks is less than the number of uncorrupted parity blocks in the received set of parity blocks. Aspect 13 receiving a second set of source blocks and a second set of parity blocks corresponding to a second frame of the audio signal; determining a second number of corrupted source blocks in the second set of source blocks; and generating a replacement audio frame in response to determining that a second number of corrupted source blocks in the second set of source blocks is greater than a number of parity blocks in the second set of parity blocks; and presenting the replacement audio frame. 13. The method of embodiment 11 or 12. Aspect 14 14. The method of claim 13, wherein the replacement audio frame includes a reduction in the output level of the audio signal. Aspect 15 15. The method of any one of aspects 11 to 14, wherein reconstructing the corrupted source blocks includes providing the set of source blocks and the set of parity blocks to a Reed-Solomon decoder. Aspect 16 16. The method of any one of aspects 11 to 15, further comprising storing the set of source blocks and the set of parity blocks in a buffer before reconstructing the corrupted source blocks, wherein the amount of audio data stored in the buffer varies over time based at least in part on packet scheduling associated with the wireless communication protocol. Aspect 17 17. The method of any one of aspects 11 to 16, wherein the wireless communication protocol is a BLUETOOTH® protocol. Aspect 18 18. The method of any one of aspects 11 to 17, wherein the version of the audio frame including the reconstructed corrupted source block is presented via a loudspeaker. Aspect 19 19. An apparatus configured to implement the method of any one of aspects 1 to 18. Aspect 20 One or more non-transitory media having stored thereon software including instructions for controlling one or more devices to perform the method of any one of aspects 1 to 18.

Claims

1. 1. A method for receiving an audio stream, comprising: receiving a set of source blocks and a set of parity blocks corresponding to a frame of an audio signal using a wireless communication protocol, the set of source blocks being at least a subset of the source blocks generated by an encoder, the set of parity blocks being at least a subset of the parity blocks generated by the encoder, and the number of source blocks and parity blocks generated and transmitted by the encoder being determined at least in part based on characteristics of the wireless communication protocol; determining a number of corrupted source blocks among the set of source blocks; determining whether to reconstruct the corrupted source blocks in response to determining that the number of corrupted source blocks is greater than zero; reconstructing the corrupted source block in response to determining that the corrupted source block should be reconstructed; and presenting a version of the audio frame including the reconstructed corrupted source block. method.

2. 2. The method of claim 1, wherein determining whether to reconstruct the corrupted source blocks comprises determining whether the number of the corrupted source blocks is less than the number of uncorrupted parity blocks in the received set of parity blocks.

3. receiving a second set of source blocks and a second set of parity blocks corresponding to a second frame of the audio signal; determining a second number of corrupted source blocks in the second set of source blocks; generating a replacement audio frame in response to determining that a second number of corrupted source blocks in the second set of source blocks is greater than a number of parity blocks in the second set of parity blocks; and presenting the replacement audio frame. The method of claim 1.

4. The method of claim 3 , wherein the replacement audio frame comprises a reduction in the output level of the audio signal.

5. 2. The method of claim 1, wherein reconstructing the corrupted source blocks comprises providing the set of source blocks and the set of parity blocks to a Reed-Solomon decoder.

6. 2. The method of claim 1, further comprising storing the set of source blocks and the set of parity blocks in a buffer before reconstructing the corrupted source blocks, wherein an amount of audio data stored in the buffer varies over time based at least in part on packet scheduling associated with the wireless communication protocol.

7. The method of claim 1 , wherein the wireless communication protocol is the BLUETOOTH protocol.

8. The method of claim 1 , wherein the version of the audio frame containing the reconstructed corrupted source block is presented through a loudspeaker.

9. The method of claim 1 , wherein the characteristics of the wireless communication protocol include at least a timing interval at which packets are transmitted.

10. a processor; a memory storing a computer program for causing said processor to carry out the method of any one of claims 1 to 9; A device having:

11. 10. One or more media having stored thereon software comprising instructions for controlling one or more devices to perform the method of any one of claims 1 to 9.

Images