This test took longer than expected because the evidence Thumb5 and others asked for in the Further discussion about configuring Diretta isn’t something Diretta exposes in simple metrics – I had to learn how to collect it from multiple layers (pcap, logs, and OS timing) and output the findings. The material below is intentionally scoped to mechanism-level behavior: what Diretta is doing above the USB layer during playback. It does not attempt to prove subjective sound-quality claims or rank Diretta versus RAAT, HQPlayer, or other transports.
@Thumb5 asked for:
concrete examples of “frequent buffer corrections,” “scheduling adjustments,” and “corrective work” above USB, and the circumstances under which they’re needed and performed.
I answer these directly at the end, after presenting the supporting captures and logs.
Why Timing Stability Matters
As I understand it, Diretta’s purpose is to reduce delivery timing variance, so the DAC performs less internal corrective work. A steadier delivery pattern allows the DAC to operate in a more stable internal state. When delivery timing is uneven, the DAC performs more corrective buffer management work upstream of conversion. These operations are bit-correct, but they are not timing-neutral. Increased internal activity near the conversion path can influence stability.
Host and Target Analysis
My analysis presents measurements and observations of timing behavior. The intent is to show where timing variability exists in a typical Linux system and how Diretta responds to that variability above the USB layer.
I will show:
- The Diretta Host is intentionally carrying complexity
- The Diretta Target is intentionally simple and stable
Test Architecture
- RPi5 Diretta Host with Roon Bridge (Audiolinux)
- RPi5 Diretta Target (Audiolinux)
- Audiolinux CPU isolation for Diretta ALSA
- IPv6LL direct connection between Host and Target
- Test stream is 24/96 FLAC files from local disc on Roon Core (Audiolinux)
- Linux standard tools (cyclictest, tcpdump)
Host vs Target Results
Host OS Scheduling Latency
Host cyclictest results show distribution of scheduling latency clustered at a few microseconds, demonstrating persistent OS wake-up variability.
Target OS Scheduling Latency
Target cyclictest results show a tighter latency distribution than the Host, indicating that upstream variability is absorbed before reaching the USB boundary.
The higher number of cyclictest samples on the Target reflects fewer missed or coalesced wakeups due to a calmer execution environment, while the Host’s lower sample count and wider latency spread reflect additional scheduling pressure from network and control activity that Diretta absorbs upstream of USB.
Host Scheduling Latency Over Time
Host scheduling latency varies continuously over time, confirming that timing variability is persistent.
The Host exhibits continuous microsecond-scale scheduling variability over time.
Target Scheduling Latency Over Time
Target scheduling latency remains consistently low during playback, confirming isolation from Host-side variability.
The Target shows consistently low and stable scheduling latency because upstream timing variability has already been absorbed before execution reaches the USB boundary. Even tighter clustering than the Host with fewer excursions often almost a straight line at ~1–2 µs. Because Diretta performs correction upstream, the Target’s scheduler is not asked to absorb bursts, is not reacting to network jitter, is not under timing pressure so its wakeups are more uniform, and more predictable.
Host Network Packet Inter-Arrival Jitter
On the Host, the UDP traffic splits into two layers: a steady stream of small control packets (24–64B) and periodic large audio payload packets (1048B). The payload packets arrive in short refill bursts with noticeable gaps between them, which is what produces spikes in the inter-arrival plot; the small packets form the low baseline.
The key point is that the audio payload is not sent as a perfectly even stream over the network. Diretta instead uses two asynchronous channels: the payload channel moves audio efficiently in bursts, while the control channel runs continuously to keep the Target’s buffer centered. The Host logs (“Stream Rest …” then “info rcv … fs=…”) match this: the Target reports buffer/timeline state (reflecting ALSA/USB consumption), and the Host makes small pacing and burst-scheduling adjustments so the Target can feed the USB DAC steadily without underruns or buffer swings.
Corrective Actions
Diretta Host performs continuous corrective actions during playback, indicating proactive closed-loop control above the USB layer.
The Target continuously reports stream remainder (buffer/timeline state) while the Host uses that feedback to apply small pacing and refill-timing adjustments (fs micro-changes). This control loop does not eliminate burst payload delivery on the network. It keeps the Target buffer centered so burst arrivals and OS timing variability do not translate into buffer swings at the ALSA/USB boundary. In steady state, the Target’s Stream Rest converges into a narrow band, indicating the controller has locked to a stable operating point while playback remains free of Target-side instability - no xruns / stable ALSA RUNNING.
Log Samples:
diretta-host syncAlsa: Target: update Stream Rest 37248 27 2
diretta-host syncAlsa: info rcv 2 -0.1270 -0.1270 0.0179 fs=195.4336
diretta-host syncAlsa: Target: update Stream Rest 39492 34 3
diretta-host syncAlsa: info rcv 2 -0.0743 -0.0743 0.0156 fs=195.0000
diretta-host syncAlsa: Target: update Stream Rest 39768 34 3
diretta-host syncAlsa: info rcv 2 -0.0676 -0.0676 0.0178 fs=195.4102
Target reports its stream state
Target: update Stream Rest 37248 27 2
What this means
- The Target is reporting its current stream remainder / buffer state
- “Stream Rest” represents how much audio data remains relative to an expected timeline
- The additional integers (e.g., 27 2) are internal counters/state indicators (e.g., cycle index, phase/state)
What is important - The Target is acting as a time reference, reporting how reality compares to expectation
- The Target is not adjusting playback, it is simply observing and reporting consumption timing
Host receives feedback and computes error
info rcv 2 -0.1270 -0.1270 0.0179 fs=195.4336
This line is the core of the closed-loop controller.
info rcv 2 → feedback frame received
-0.1270 -0.1270 → timing/phase error terms (signed)
0.0179 → small adjustment increment (control output)
fs=195.4336 → effective stream frequency after correction
What this means
The Host:
- Receives Target timing feedback
- Computes the timing error (early/late)
- Applies a small frequency/pacing adjustment
- Updates its internal stream rate (fs)
Correction converges over successive cycles
Next pair:
Target: update Stream Rest 39492 34 3
info rcv 2 -0.0743 -0.0743 0.0156 fs=195.0000
Then:
Target: update Stream Rest 39768 34 3
info rcv 2 -0.0676 -0.0676 0.0178 fs=195.4102
What’s happening
- The magnitude of the error term decreases (-0.1270 → -0.0743 → -0.0676)
- The Host adjusts fs slightly up or down
- The system hunts gently around the target rate
- This is closed-loop convergence behavior.
Target logs show Diretta starting a control loop (controlLoop start) and configuring the ALSA-facing stream (Connect [SYNC ALSA], set LATENCY 20msec, State Change : Play). During playback the Target continuously emits update Stream Rest … telemetry, which is the Target-side measurement of stream remainder/buffer-timeline state. Host logs show the paired response (info rcv … fs=…), indicating the Host computes signed timing error terms and applies micro-adjustments to pacing and refill scheduling. Combined with Wireshark evidence of small bidirectional control packets (24–64B) alongside periodic large payload bursts (1048B), this demonstrates continuous corrective control above USB that keeps the Target buffer centered so ALSA/USB remains stable despite burst payload delivery.
The Target continuously reports stream remainder (“Stream Rest”) during playback
diretta-target: update Stream Rest 37248 27 2
diretta-target: update Stream Rest 39492 34 3
diretta-target: update Stream Rest 39768 34 3
This is the Target producing frequent telemetry about its stream/buffer state. The repeated “update Stream Rest …” lines are the Target-side evidence of the “frequent buffer corrections / corrective work” conversation.
Target ALSA Buffer Behavior During Playback
These figures summarize how the Target’s ALSA playback buffer behaves during steady-state Diretta playback. They are intended to show whether the Target is being fed in a way that keeps the playback queue stable (no underruns, no runaway fill), even though upstream delivery can arrive in bursts.
Buffer refill / drain events over time
Change in ALSA reported delay per 1 Hz sample; large drops/peaks indicate discrete drain/fill transitions.
What this shows:
- Most samples move in a narrow band, indicating small, continuous adjustments in queued audio.
- Regular larger negative steps are consistent with periodic buffer refills (the writer catching up after a drain).
- There is no pattern consistent with an underrun (no prolonged collapse to very low delay).
Queued audio vs writer pressure
ALSA delay (queued frames) plotted alongside write pressure (avail_max - avail).
What this shows:
- Delay shows a repeating pattern: the buffer gradually drains, then is refilled.
- Write pressure rises as the buffer drains and drops after refills, consistent with normal paced writing into ALSA.
- The two traces move together in a way that indicates controlled buffering rather than reactive ‘panic’ refills.
ALSA ‘delay’ is the amount of audio already queued for playback (in frames). In stable playback, delay should remain within a controlled band and show regular refill cycles rather than erratic swings or underruns.
Test Conditions
Testing was performed with Diretta Host → Diretta Target feeding a USB DAC, with simultaneous captures of (1) Host/Target cyclictest scheduling latency, (2) Host-side UDP traffic (Wireshark/tshark pcap), (3) Diretta Host/Target logs, and (4) Target ALSA /proc/asound/…/status at ~1 Hz during playback. Playback was run at 24-bit / 96 kHz with the Target buffering/latency and control parameters set in the Diretta configuration LatencyBuffer=78000, InfoCycle=12000, CycleTime=10000, CycleMinTime=100, periodMin/Max, periodSizeMin/Max, syncBufferCount=12, alsaUnderrun=enable. Captures were taken over a 5-minute window.
Test Summary
This test shows that Diretta maintains stable playback by separating bulk audio delivery from timing control above the USB layer. On the Host, network and OS timing are variable (cyclictest latency varies over time and Wireshark shows audio payload delivered in periodic burst packets alongside continuous small control packets), while Host and Target logs show a closed-loop feedback mechanism where the Target repeatedly reports stream remainder (“Stream Rest”) and the Host applies small pacing/burst-scheduling adjustments (“info rcv… fs=…”) until the Target converges to a steady buffer state. On the Target side, ALSA is explicitly configured (including a latency target) and remains stable during playback (no xruns/USB instability observed).
I believe my hypothesis holds, keeping the Target’s buffer and playback pipeline in a steadier operating state reduces buffer churn and corrective activity near the conversion path, which can plausibly reduce noise modulation and timing-related stress around the DAC conversion pipeline and is a credible reason why listeners perceive improved image stability and decay even though the audio remains bit-correct.
Thumb5 asked for the following evidence:
1 Please provide concrete examples of the “frequent buffer corrections”, “scheduling adjustments” and “corrective work” that you assert are needed above the USB layer?
2 Under what circumstances are they needed and performed?
1) Concrete examples of “frequent buffer corrections”, “scheduling adjustments”, and “corrective work” above USB
A) “Frequent buffer corrections”
Concrete Evidence:
- Host log feedback loop lines showing continuous measurement and micro-adjustment:
- Target: update Stream Rest … (Target reporting stream remainder / buffer-timeline state)
- info rcv … fs=… (Host computing error terms and updating effective pacing)
- Wireshark traffic split showing:
- small control/feedback packets (24–64B)
- large payload packets (1048B) delivered in refill bursts
What this demonstrates (above USB):
- The system is continuously steering buffer state (keep Target buffer centered) via feedback.
- The “correction” is not a hard resync; it’s frequent, small, closed-loop pacing control.
The Target reports Stream Rest and the Host responds with info rcv … fs=… updates repeatedly during playback; these are continuous buffer/timeline corrections applied before USB.
B) “Scheduling adjustments”
Concrete Evidence:
- Host cyclictest shows OS wakeup latency variance (distribution + time series).
- Target cyclictest shows different scheduling behavior (tighter distribution, higher wake count), confirming the Target is behaving more deterministically near the USB edge.
- You can also point to the Host/Target running real-time priorities in Diretta (Priority set HIGH in logs).
What this demonstrates (above USB):
- Scheduling variance exists upstream; Diretta mitigates it by:
- using real-time thread priorities,
- smoothing delivery through pacing corrections,
- keeping the Target insulated.
cyclictest shows non-zero wakeup latency on the Host during playback; Diretta runs high-priority worker/buffer threads and uses Target feedback to compensate so the Target/USB side remains stable.
C) “Corrective work”
Concrete Evidence:
- Diretta corrective actions graph (events over time) showing continuous corrective activity rather than rare recovery.
- Host log showing what those corrections are:
- signed error terms
- control output increment
- fs= adjustments (“effective stream frequency after correction” as interpreted)
What this demonstrates (above USB):
- Corrections are:
- small
- frequent
- continuous
- based on Target feedback
- applied to stream pacing before USB
Host log lines show repeated cycles of Target state reporting and Host error/pacing updates (info rcv … fs=…), which is direct evidence of closed-loop corrective work above USB.
2) Under what circumstances are they needed and performed?
When they are needed
They’re needed whenever upstream timing is not perfectly deterministic - which is essentially always in a general-purpose OS + network path. Specifically the data shows:
- Host OS scheduling variability
- cyclictest shows wakeup latency jitter exists even in baseline playback.
- Host network delivery is bursty at the payload layer
- Wireshark shows large payload packets (~1048B) arriving in bursts with gaps.
- The inter-arrival plot shows large spikes corresponding to these gaps.
- Clock-domain mismatch and drift (inevitable)
- Host send pacing and Target consumption pacing must be continuously reconciled, even if the DAC clock is independent.
When they are performed
They are performed continuously during playback:
- Control/feedback packets (24–64B) flow continuously → this is the measurement/control cadence.
- Payload refills (1048B) occur periodically in bursts → this is the bulk transfer mechanism.
- Host log “Stream Rest/info rcv/fs=” cycles occur repeatedly → this is the ongoing correction mechanism.
- The Target remains stable (no xruns, ALSA RUNNING) while this is happening → correction is upstream, not at USB.
They are performed continuously during normal playback because the Host OS and network do not deliver perfectly uniform timing. The Target reports buffer/timeline state continuously; the Host applies frequent micro-adjustments to pacing and refill scheduling, so burst payload delivery does not translate into buffer swings or USB/ALSA instability.
Missing from the above evidence is what Host setting.inf tuning is doing
Even though the Target never tells the DAC what to do, the Target absolutely controls the conditions under which ALSA/USB is being fed - buffer depth, refill cadence, period size/count, wake-up frequency, and how often the pipeline gets close to underrun/overrun. Those conditions can change how much work the OS/USB stack does near playback time, and how bursty upstream delivery gets translated into a monotonic stream at the USB boundary. This is where tuning parameters live.
setting.inf changes how aggressively Diretta smooths, and how often the system needs to touch the audio pipeline to keep it stable. If you reduce buffer excursions and reduce near-deadline work (wakeup jitter, emergency refills, underrun recovery behavior), you can plausibly reduce timing-related churn and noise modulation in the playback path - even though the bits and the DAC clock remain correct.
That’s the hypothesis-friendly bridge between control loop + buffers and audible differences.
What these knobs are likely doing:
I’m not claiming exact vendor definitions, but the names line up strongly with typical streaming/control-loop parameters.
- Control loop cadence and aggressiveness
-
InfoCycle=12000
interval at which Target↔Host control/feedback messages are exchanged (or how often info is processed). Lower = more frequent updates (tighter control), higher = less chatter (looser control). -
CycleTime=10000 / CycleMinTime=100 / FlexCycle=semi
main scheduling period for the send/consume cycle, with FlexCycle allowing adaptation and CycleMinTime acting as a floor. These affect how even the internal pacing is versus how much it batches. -
TargetProfileLimitTime=180
clamp/limit on how far the profile/controller can push corrections (a stability guardrail). -
ThredMode=2048
selects thread behavior: RT priority strategy, busy-wait vs sleep, core affinity behavior, etc. This can drastically change scheduling jitter and wakeup patterns.
Why: tighter/cleaner control can keep the Target buffer closer to a steady setpoint, reducing refill drama and deadline pressure.
- ALSA/USB-facing buffering and wakeup behavior
These matter a lot because ALSA period scheduling is literally how often Diretta wakes up and moves audio.
-
periodMin=16 / periodMax=32
period count bounds (or some period parameter bounds). More periods generally = more buffering / fewer underrun risks, but also potentially more latency. -
periodSizeMin=512 / periodSizeMax=1536
ALSA period size bounds (frames). Smaller periods = more frequent wakeups and tighter timing demands; larger periods = fewer wakeups, more buffering, potentially less scheduler stress. -
syncBufferCount=12
number of internal buffers queued/managed in the Diretta sync layer. Higher can smooth burst input more; too high can increase latency and blur the responsiveness of the control loop. -
LatencyBuffer=78000
an internal target buffer depth (possibly in µs or frames). This is a direct how much safety margin do we keep? knob. -
alsaUnderrun=enable
control underrun handling strategy (whether to detect/recover in a certain way, log, or change behavior). This doesn’t fix sound directly, but it changes how the system behaves near failure conditions.
Why: These parameters determine whether the Target spends its life in a calm steady state (buffer centered, predictable wakeups) or a reactive one (frequent refills, frequent wakeups, occasional close calls). Even if USB is periodic, the host controller and kernel still schedule work, keeping the system away from edge conditions can reduce incidental activity near playback time.