Audio Latency

Audio latency measures the end-to-end delay from audio capture (I2S DMA or USB input) on the TX device to playback start on the RX device. It builds on top of wireless latency.

Figure 52: Audio latency composition in the min, typical, and max cases for the SDK audio_unidirectional example on SR1100. The Wireless component drives the small typical variation, and an extra TX Buffer packet appears in the worst case when the wireless send-to-free time exceeds one packet duration. Per-application diagrams appear on each example page.

Initial Buffering

When the pipeline is configured with do_initial_buffering = true (default for audio playback), the consumer endpoint does not begin playback until its queue is completely filled. This introduces a one-time startup latency:

\[L_{\text{startup}} = \text{rx_queue} \times \text{packet_duration}\]

Because the wireless slot rate is higher than the audio packet rate, this startup buffer progressively migrates from TX to RX as the link starts: audio packets initially accumulate in the TX queue while the link is coming up, then drain from TX faster than the source produces them once transmission starts, filling the RX queue until playback begins. The total buffered latency is unchanged; only the physical location of the samples shifts.

Figure 53: Buffer migration on startup.

The three phases visible above:

• Buffering: the audio source produces packets while no OTA audio is being sent yet; the TX queue grows at the audio packet rate and the RX queue is empty.

• Stream startup: the wireless audio stream begins; wireless drains the TX queue faster than the source produces new packets, so TX drops while RX fills.

• Steady state: playback starts when RX reaches its configured target and CDC maintains that level.

Note

Order of magnitude on a perfect link (no packet loss, no retry) using the SDK audio_unidirectional example on SR1100:

• wireless slot rate = 48 slots / 9.8 ms = 4898 slots/s

• audio packet rate = 1 / 271 us = 3690 pkt/s

• rx_queue target = 11 packets

Once the wireless link starts transmitting, RX fills at the wireless slot rate (the link is faster than the source, so the accumulated TX packets drain fast). Playback starts after:

\[T_{\text{ramp}} \approx \frac{\text{rx_queue target}}{\text{wireless slot rate}} = \frac{11}{4898} \approx 2.25\ \text{ms}\]

This is bounded below by \(11 / 4898 \approx 2.25\) ms (wireless drains a full TX accumulation at slot rate) and above by \(\text{rx_queue} \times \text{packet_duration} = 11 \times 271\ \mu s \approx 2.98\) ms (degenerate case: TX had nothing buffered when the link came up, so RX fills at the slower source rate).

After the initial fill, the pipeline operates in steady state and the RX queue level is maintained by the clock drift compensation (CDC) mechanism. The startup latency is included in the steady-state formulas below (as the rx_queue term).

Pipeline Stages

Figure 54: Audio pipeline stages. Boxes on the left run on the TX device, the wireless segment carries the audio packet over the air, and boxes on the right run on the RX device.

Stage	Description	Duration
TX Endpoint	Source input processing (codec ADC on I2S; effectively 0 for USB)	Hardware-dependent (see codec note below)
Capture	Time to accumulate one audio packet worth of samples from the source (e.g. I2S DMA fills one packet, sample by sample, at the codec rate)	1 x packet_duration on I2S; see Capture Latency by Endpoint Type
TX Processing	Application-layer encode/DSP	Configurable
Wireless	Radio transit (see Wireless Latency)	wireless_min to wireless_max
RX Processing	Application-layer decode/DSP	Configurable
RX Queue	Playback buffer absorbs jitter	rx_queue_packets * packet_duration
RX Endpoint	Sink output processing (codec DAC on I2S; effectively 0 for USB)	Hardware-dependent (see codec note below)

Note

The codec latency depends on the specific audio codec hardware used and the operating sample rate. For the SPARK EVK boards using the MAX98091 codec at 48 kHz in Music mode (FIR filter):

• ADC path (record): 0.8 ms

• DAC path (playback): 0.76 ms

• Total: 1.56 ms

At lower sample rates, the codec delay increases (inversely proportional to sample rate). For example, at 8 kHz the delay is approximately 4.5 ms per path.

Different codecs or different operating modes will have different delays. Consult the codec’s datasheet for the path phase delay specification at your operating sample rate. The CODEC_LATENCY_MS parameter in sac_cfg.h should be set to the sum of ADC + DAC delays for your hardware at the target sample rate.

Processing Stage Latency

Some audio processing stages introduce additional pipeline latency beyond the basic capture-wireless-playback chain.

Sample Rate Converter (SRC)

When the audio stream requires sample rate conversion (e.g., 48 kHz I2S to 32 kHz OTA), the SRC processing stage introduces a group delay from its FIR anti-aliasing filter(s). The default FIR is FIR_NUMTAPS = 24 taps, giving a linear-phase group delay of \((N-1)/2 \approx 12\) samples per filter measured at that filter’s operating rate.

The SDK implementation (core/audio/processing/sac_src_cmsis.c) runs the interpolator first and the decimator second when both are active, connected by an intermediate buffer at rate \(F_{\text{int}} = L \times F_{\text{in}}\) (where \(L\) = multiply_ratio and \(D\) = divide_ratio). Depending on which stages are active:

SRC configuration	Filter rate(s)	Group delay per SRC instance
Pure decimation (\(L=1\), \(D>1\))	Decimator at \(F_{\text{in}}\)	\(12 / F_{\text{in}}\)
Pure interpolation (\(L>1\), \(D=1\))	Interpolator at \(L \times F_{\text{in}}\)	\(12 / (L \times F_{\text{in}})\)
Rational (\(L>1\), \(D>1\))	Both filters at \(L \times F_{\text{in}}\)	\(24 / (L \times F_{\text{in}})\)

Example: audio_bidirectional back channel (48 kHz I2S ↔ 32 kHz OTA), which uses a rational SRC on both endpoints:

Direction	L / D (intermediate)	Group delay
NODE TX (48 → 32)	L=2, D=3 (96 kHz)	24 / 96000 = 0.25 ms
COORD RX (32 → 48)	L=3, D=2 (96 kHz)	24 / 96000 = 0.25 ms
Total both sides		0.50 ms

Clock Drift Compensation (CDC)

The CDC software resampling mechanism does not introduce pipeline delay. It operates on each incoming packet immediately and applies a single sample add/drop correction at the end of a resampling period (default: 1440 samples). The correction is transparent to the latency model.

Note

The CDC resampling period (cdc_resampling_length / sample_rate, default 30 ms at 48 kHz) defines the detection averaging window, not a buffering delay. No samples are held back waiting for the window to complete.

Note

Beyond drift correction, CDC also drives the receive queue to a configurable target queue size, which lets the application change the effective playback latency at runtime (see Clock Drift Compensation). This is how the puretone examples couple audio latency with the current fallback mode without reconfiguring the pipeline.

Sample Accumulator

The sample accumulator processing stage collects multiple input packets into a single larger output packet. This is used in fallback modes to increase the number of samples per OTA packet (e.g., from 40 to 68 or 92 samples) without changing the I2S DMA packet size.

The accumulator introduces latency equal to the time it takes to collect the additional samples beyond the first input packet:

\[L_{\text{accumulator}} = \left(\frac{\text{accumulator_size}}{\text{input_payload_size}} - 1\right) \times \text{input_packet_duration}\]

Where accumulator_size = (input_payload_size * mul) / div and the mul/div ratio is configured per fallback mode.

Mode	Ratio (mul/div)	Packets collected	Accumulation delay	Notes
Normal (no accumulation)	1/1	1.0	0 ms	Pass-through
Fallback 1, 2 (1.7x)	17/10	1.7	0.29 ms	At 96 kHz, 40 samples/packet
Fallback 3 (2.3x)	23/10	2.3	0.54 ms	At 96 kHz, 40 samples/packet

Note

The accumulator operates before the SRC (downsampling) stage. Its latency is incurred at the input sample rate (96 kHz for puretone applications). The accumulated packet is then decimated by the SRC to produce the OTA payload at the target rate.

System Latency Overhead

The Audio Core (SAC) defines a fixed system latency overhead of 3 packets (SAC_SYSTEM_LATENCY_PKT):

• 1 packet for DMA transfer latency (I2S double-buffering: one buffer is always being filled while the other is consumed).

• 2 packets for wireless queue pipeline depth.

This constant is used in the SAC_CALCULATE_LATENCY_QUEUE_SIZE macro when computing the user-configurable RX queue depth from a target latency.

Derivation of the 2-Packet Wireless Estimate

The “2 packets for wireless queue” value is derived from the typical wireless send-to-free latency in the SDK audio examples. It represents the maximum number of audio packets that can be simultaneously committed to (i.e., waiting inside) the wireless TX queue:

\[\text{wireless_queue_packets} = \left\lceil \frac{L_{\text{send_to_free}}}{\text{packet_duration}} \right\rceil\]

Where \(L_{\text{send_to_free}}\) is the time from swc_connection_send() until the TX success callback frees the queue slot (send_done()):

\[L_{\text{send_to_free}} \approx E[\text{wait}] + \text{CCA} + \text{airtime} + \text{ACK_turnaround} + \text{ACK_airtime} + \text{processing}\]

For the SDK audio_unidirectional example on SR1100 (a 9.8 ms schedule period of 49 timeslots of 200 us each: 48 coordinator audio TX slots plus 1 node uplink slot; 13 samples at 48 kHz per packet):

• packet_duration = 13 / 48000 = 271 us

• Typical inter-opportunity gap between adjacent audio TX slots = 200 us (one timeslot); a single 400 us gap occurs once per schedule period, from the last coordinator audio slot to the first audio slot of the next period, spanning the node uplink slot

• E[wait] ~= 100 us (half the typical gap)

• Fixed components (CCA + main airtime + ACK round-trip + RX processing) on the order of ~150 us for this schedule and PHY configuration

• L_send_to_free ~= 250 us

Because L_send_to_free is on the order of one packet duration for this schedule, the 2-packet reservation is a conservative rounding up: it covers both the packet currently in flight and one waiting behind it in the TX queue during typical retransmission activity.

Warning

The constant SAC_SYSTEM_LATENCY_PKT = 3 is calibrated for the SDK audio example schedules. If your schedule design differs significantly (fewer TX slots, longer schedule period, or shorter packet duration relative to the wireless slot rate), the 2-packet wireless estimate may undercount. In that case, compute the correct value using the formula above and adjust your TX queue size accordingly to avoid audio packet drops.

Capture Latency by Endpoint Type

Endpoint	Capture Duration
I2S	1 x packet_duration (DMA fills one packet)
USB High-Speed	ceil(packet_duration / 125 us) x 125 us
USB Full-Speed	1.0 ms (one USB frame)

Packet Duration

\[\text{packet_duration_ms} = \frac{\text{sample_count}}{\text{sampling_rate}} \times 1000\]

TX Buffering

While the radio is busy or waiting for a slot, the audio source continues producing packets. The number of packets that accumulate in the TX buffer:

\[\text{tx_buffered_max} = \max\!\left(0,\; \left\lceil \frac{\text{max_gap_ms}}{\text{packet_duration_ms}} \right\rceil - 1 \right)\]

\[\text{tx_buffered_typ} = \max\!\left(0,\; \left\lceil \frac{\text{typ_gap_ms}}{\text{packet_duration_ms}} \right\rceil - 1 \right)\]

Total Audio Latency Formulas

Let:

\[\text{fixed} = \text{capture} + \text{tx_endpoint} + \text{tx_proc} + \text{rx_proc} + \text{rx_endpoint}\]

Minimum:

\[L_{\text{audio,min}} = \text{fixed} + (0 + \text{rx_queue}) \times \text{packet_duration} + L_{\text{wireless,min}}\]

Maximum:

\[L_{\text{audio,max}} = \text{fixed} + (\text{tx_buffered_max} + 1 + \text{rx_queue}) \times \text{packet_duration} + L_{\text{wireless,max}}\]

Typical:

\[L_{\text{audio,typ}} = \text{fixed} + (\text{tx_buffered_typ} + \text{rx_queue}) \times \text{packet_duration} + L_{\text{wireless,typ}}\]

Overflow Detection

Audio delivery is sustainable only when the delivery rate meets or exceeds the generation rate:

\[\text{generation_rate} = \frac{\text{sampling_rate}}{\text{sample_count}}\]

\[\text{delivery_rate} = \text{available_frame_rate} \times (1 - \text{loss_rate})\]

Overflow occurs when delivery_rate < generation_rate.

Suggested RX Queue Depth

To meet a target typical latency:

\[\text{rx_queue} = \left\lfloor \frac{\text{desired_latency} - L_{\text{wireless,typ}} - \text{fixed}}{\text{packet_duration}} \right\rfloor - \text{tx_buffered_typ}\]

Where \(\text{fixed}\) is the contribution from the endpoint and processing stages defined in Total Audio Latency Formulas (\(\text{fixed} = \text{capture} + \text{tx_endpoint} + \text{tx_proc} + \text{rx_proc} + \text{rx_endpoint}\)).

Important

Configure at least 3 packets for the RX queue. CDC corrects clock drift by adding or dropping single samples to steer the queue toward its target, and normal wireless jitter perturbs the queue level around that target by up to one packet. With fewer than 3 packets, drift plus jitter easily push the queue to zero and produce audible glitches even on an otherwise healthy link.

Note

The SAC_CALCULATE_LATENCY_QUEUE_SIZE macro in sac_utils.h performs this calculation, subtracting the 3-packet system overhead automatically.

Important

The typical latency is designed to be below the target by less than one packet duration. This is intentional. The RX queue depth (computed by the macro using integer division) sets a discrete number of packets. The target latency acts as an upper bound: the system is designed so that the typical end-to-end latency stays below the target, with the remaining margin (always less than one packet) providing headroom to absorb jitter without underflow. If the typical latency exceeded the target, the consumer would underflow during normal operation.

Retransmission Jitter Absorption

When the underlying wireless connection uses retransmissions (limited retry, deadline, or guaranteed delivery; see Retransmission Impact (Stop-and-Wait ARQ)), the audio pipeline queues on both ends act as buffers that absorb retransmission jitter. A larger queue tolerates higher instantaneous PER without interruption of service but increases steady-state end-to-end latency. Queue sizing is therefore a direct tradeoff between robustness under bursty interference and audio latency.

In guaranteed-delivery mode the Wireless Core will keep retrying the head packet, so it is the audio pipeline’s producer queue that ultimately bounds in-flight backlog and controls where a frame is dropped when the link cannot keep up.

Buffer as Burst-Bridge

The primary role of the audio pipeline’s queues for perceived quality is to bridge over interference bursts so that playback continues while the wireless connection cannot deliver. Small pipeline jitter is a secondary concern already covered by Retransmission Jitter Absorption above.

Real-world wireless interference is bursty, not statistically stationary. On a healthy link the raw over-the-air PER is near zero for most of the time; during interference events (a nearby Wi-Fi transmit burst, a colliding concurrent SPARK network’s frame, motion-induced fading, obstacles) the effective PER on the connection can approach 100 % for the burst’s duration, then drop back to near zero when the event ends. Two consequences follow:

• A “steady-state PER” is not something you can measure in the field, and any robustness metric that assumes stationary PER gives false precision. It cannot predict a real deployment’s audio quality.

• The buffer’s practical job is a duration bet: any burst of length \(\leq L_{\text{buf}}\) is invisible to the listener because the buffer drains during the burst and refills afterwards without ever hitting zero. Any burst longer than \(L_{\text{buf}}\) empties the queue and produces an audible glitch of duration \(\text{burst} - L_{\text{buf}}\).

The mechanism is illustrated below: the queue drains during a burst at the playback rate; if the burst ends before the queue hits zero the link recovers seamlessly; if it does not, playback stalls until arrivals resume.

Figure 55: Buffer-bridge behaviour under a burst of consecutive packet losses. Both panels use the same \(L_{\text{buf}} = 5\) packets and the same steady arrival/consumption rate; only the burst duration differs. Case A (left): a 3-packet burst; the queue drops from 5 to 2 and refills after the burst, no glitch. Case B (right): an 8-packet burst; the queue drains to zero after 5 slots without arrivals, playback stalls for the remaining 3 slots of the burst, producing an audible glitch. The underrun stops when arrivals resume.

Buffer robustness therefore separates into two independent design concerns.

Schedule design (retransmission margin)

The wireless schedule must give the connection enough TX opportunities to sustain the application packet rate on average, allowing for retransmissions under the average link condition. This is captured by the Retransmission Margin:

\[f_{\text{slot}} \times (1 - \text{PER}_{\text{avg}}) \;\geq\; f_{\text{pkt}}\]

where \(f_{\text{slot}}\) is the connection’s TX slot rate, \(f_{\text{pkt}}\) is the application packet rate, and \(\text{PER}_{\text{avg}}\) is the average link PER expected in the deployment (from link-budget analysis or bench measurement). Rearranging gives the retransmission margin directly:

\[R \;=\; 1 - \frac{f_{\text{pkt}}}{f_{\text{slot}}} \;\geq\; \text{PER}_{\text{avg}}\]

So the retransmission margin \(R\) is the maximum sustainable \(\text{PER}_{\text{avg}}\) the schedule can absorb. Below the ceiling the queue stays drained on average; above it the queue backs up permanently and no amount of buffer can help. This is a schedule-design decision made when the schedule is defined, not a buffer-sizing decision made when the audio pipeline is configured. The SDK audio_unidirectional example has \(f_{\text{pkt}} = 3692\) pkt/s over \(f_{\text{slot}} = 4898\) slots/s, giving \(R \approx 25\ \%\), i.e. the schedule tolerates an average PER up to 25 % without backing up.

Retries increase the effective delivery rate exponentially in the retry count, at the cost of additional latency per attempt. For a fixed audio latency budget (5 ms in the SDK audio_unidirectional example), a few retries fit comfortably within the buffer margin.

Figure 56: Burst-coverage slice at the audio_unidirectional operating point (fixed \(L_{\text{buf}} = 5\) ms), showing what the pipeline absorbs as the retransmission margin \(R = 1 - f_{\text{pkt}}/f_{\text{slot}}\) varies. Five illustrative burst-duration scales are shown: \(\tau = 1\), \(2\), \(3\), \(5\), \(10\) ms. These scales bracket a plausible range but are not measured deployment values; actual burst statistics must come from bench measurement of the target RF environment. Retries shorten the effective burst seen by the buffer by factor \((1 - R)\), so every curve lifts as \(R\) grows. Vertical markers at \(R = 10\), \(25\) (audio default), \(50\), \(75\), \(85\) %. The Y axis is zoomed to 80-100 %, so \(\tau = 5\) and \(\tau = 10\) enter the plot from the bottom where their coverage crosses 80 %.

At the audio default \(R \approx 25\ \%\) the readout is:

• \(\tau = 1\) ms burst → 99.9 % bridged

• \(\tau = 2\) ms burst → 96.4 % bridged

• \(\tau = 3\) ms burst → 89.2 % bridged

• \(\tau = 5\) ms burst → 73.6 % bridged

• \(\tau = 10\) ms burst → 48.7 % bridged

Even the 99.9 % row is not “always”: in an environment producing several bursts per second, a fraction of a percent of unbridged bursts still translates into audible glitches over a listening session. Retx margin alone cannot make the buffer glitch-free; it moves the curve, and the sizing graph below is needed to close the remaining gap.

The complementary view in Buffer sizing (burst tolerance) fixes \(R = 25\ \%\) and varies \(L_{\text{buf}}\) on the X axis.

Important

Retransmissions act directly on \(\text{PER}_{\text{avg}}\): a packet is only declared lost after all attempts fail, so with \(n\) retries the effective loss the audio pipeline sees is \(\text{PER}_{\text{eff}} \approx \text{PER}_{\text{avg}}^{\,n+1}\) when losses are independent. This is the link between retransmissions and the \(\text{PER}_{\text{avg}}\) ceiling above: each retry lowers the effective \(\text{PER}_{\text{avg}}\) the schedule must absorb.

The graph above assumes losses are independent within a burst. Real interference is burst-correlated (retries during a burst are also likely to fail), so a higher ReTX Margin helps less against long dense bursts than the model predicts. Use retransmissions to plug isolated failures and to allow post-burst catch-up; use buffer \(L_{\text{buf}}\) for the burst-duration tolerance itself.

Buffer sizing (burst tolerance)

Given a schedule with sufficient retransmission margin, the queue depth \(L_{\text{buf}}\) determines how long a burst of dropped packets the link can bridge without an audible glitch. \(L_{\text{buf}}\) is the RX + TX queue portion of latency only, not the end-to-end audio latency (see the full breakdown in Total Audio Latency Formulas).

The following idealised model gives the shape of the tradeoff. If burst durations in the deployment follow an approximately exponential distribution with mean \(\tau\), then the probability that a random burst is short enough to be bridged by the buffer is:

\[P(\text{burst bridged}) \;=\; 1 - e^{-L_{\text{buf}} / (\tau \cdot (1 - R))}\]

Retries shorten the effective burst duration seen by the buffer by factor \((1 - R)\), so a higher retransmission margin lifts the coverage without changing \(L_{\text{buf}}\). The formula reduces to \(1 - e^{-L_{\text{buf}}/\tau}\) when no retransmissions are configured (\(R = 0\)).

Figure 57: Complementary view of the previous graph: the retransmission margin is fixed at \(R = 25\ \%\) (audio_unidirectional default) and buffer latency \(L_{\text{buf}}\) varies on the X axis. Same five illustrative burst-duration scales: \(\tau = 1\), \(2\), \(3\), \(5\), \(10\) ms (chosen to bracket the range, not measured). For each curve, the first few milliseconds of buffer capture most of the coverage; adding buffer past roughly \(3\tau/(1-R)\) yields negligible additional gain. At the audio_unidir configured \(L_{\text{buf}} = 5\) ms, the values match the R = 25 % column of the previous graph.

Important

The curves are illustrative, not predictive. Actual burst-duration distributions depend on the RF environment (concurrent Wi-Fi, other SPARK networks, obstacles, motion) and are best determined by bench measurement of the target deployment. The diminishing-returns shape is robust regardless of the exact distribution: because short bursts are far more common than long ones, each additional millisecond of buffer bridges progressively rarer events. The 15-packet buffering rule of thumb (see Buffering Rule of Thumb below) is expressed in packets, so its \(L_{\text{buf}}\) equivalent scales with packet duration; for the audio_unidirectional example (271 µs packets) it corresponds to \(L_{\text{buf}} \approx 4\) ms.

Combined view: puretone_unidirectional fallback modes

The two previous graphs each held one design lever fixed while varying the other. Real adaptive audio applications move both levers together. The puretone_unidirectional example is the canonical case: as the wireless link degrades, it steps through fallback modes that simultaneously increase the audio buffer latency and raise the retransmission margin via the sample accumulator.

The sample accumulator groups multiple I2S packets into one OTA packet by ratio \(k\), which reduces the OTA packet rate by the same factor. Since the wireless slot rate is unchanged, the retransmission margin \(R = 1 - f_{\text{pkt}}/f_{\text{slot}}\) grows with \(k\). Assuming the normal mode is designed for \(R = 25\ \%\) (\(f_{\text{pkt}}/f_{\text{slot}} = 0.75\)), the effective margin per mode is:

Mode	\(L_{\text{buf}}\) (ms)	Accumulator (mul / div → \(k\))	Effective R	Config source
0 (Normal)	5	1 / 1 → 1.0	25 %	MAIN_CHANNEL_FBK_0_LATENCY_MS
1	7	17 / 10 → 1.7	55.9 %	MAIN_CHANNEL_FBK_1_LATENCY_MS
2	10	17 / 10 → 1.7	55.9 %	MAIN_CHANNEL_FBK_2_LATENCY_MS
3	15	23 / 10 → 2.3	67.4 %	MAIN_CHANNEL_FBK_3_LATENCY_MS

Values are read from app/example/puretone_unidirectional/config/sac_cfg.h (MAIN_CHANNEL_ACC_MUL / MAIN_CHANNEL_ACC_DIV arrays for \(k\)).

Figure 58: Fraction of interference bursts fully bridged in each puretone_unidirectional fallback mode, for the same five illustrative burst-duration scales as the previous graphs (\(\tau = 1, 2, 3, 5, 10\) ms). Fallback mode index runs on the X axis with each mode’s \((L_{\text{buf}}, k, R)\) parameters below the tick label. Each line traces the coverage of one \(\tau\) value as fallback deepens; robustness improves for every scale as the mode index grows. The steepest gain is on \(\tau = 10\) ms, which climbs from 48.7 % (Mode 0) through 79.6 % (Mode 1) and 89.6 % (Mode 2) to 99.0 % (Mode 3); the shorter scales saturate at ~100 % by Mode 2. The tradeoff is end-to-end latency, which grows from 5 ms to 15 ms across the same range.

Note

This is why puretone-style adaptive fallback outperforms a single fixed \((L_{\text{buf}}, R)\) design point at both ends of the RF-quality spectrum: in a clean environment it stays in Mode 0 with a 5 ms latency budget, and in a degraded environment it trades latency for burst tolerance without reconfiguring the pipeline.

Diagnostics

When a deployment shows audible glitches, the useful measurement is burst duration and frequency, not average PER. A link with under 1 % average PER can still produce audible glitches if brief bursts of concentrated loss exceed \(L_{\text{buf}}\); conversely, a link with 10 %+ average PER can play cleanly if every failure is a short isolated event that fits inside the buffer.

See also

For the general concept of queues absorbing retransmission jitter, see Retransmission Jitter Absorption above.

Buffering Rule of Thumb

As a general guideline for real-time streaming applications, set the total buffering length (expressed as latency) to a duration equal to approximately 15 transmissions of the associated connection. In other words, the device should be able to transmit 15 packets in a period equal to the added latency.

For example, if a buffer length of 5 ms is desired, the associated connection should be able to send packets at greater than 3000 packets/second (15 packets / 5 ms). The RX buffer of the receiver should have the same size as the TX buffer of the transmitter.

This guideline ensures the system can absorb typical PER spikes without interruption of service while keeping latency bounded.

See also

The wireless transit component is detailed in Wireless Latency.