Diretta requires IPv6
Many would agree that Diretta can minimize cpu noise and “time-domain error” in the packet flow - shall we call it jitter? - in the target cpu when optimally configured.
What is your theory as to how those two phenomena propagate to a connected DAC to produce the above sonic traits, assuming that it’s using asynchronous USB and good noise isolation mechanisms are in place (be them in the DAC itself or between the target cpu and the DAC)?
2 Likes
It’s ok. I didn’t really understand what it was either until I dug into the logs and first determined what the issues were and then how to properly configure OS settings and the Diretta Host setting.inf. Most of what you’ll find out there for host settings is a misconfiguration because of a misunderstanding of how CycleTime, syncBufferCount, LatencyBuffer, and CPU isolation together define how predictably audio leaves the host, and adjusting any one in isolation usually degrades stability rather than improving sound. You’ve already invested in the RPi’s, and configured them based on David Snyder’s guide - so you’re 90% there. I would say the correct settings will take you under 30 minutes to configure both Host and Target. PM me and I can send you a pdf.
Does this miconfiguration comes from Diretta? I think that would be a glaring omission on their part.
Thanks, I appreciate it. I’m sure @David_Snyder will be interested in this, not to mention Diretta themselves. It seems to me they are not aware of it, or they would publish it somewhere or simply correct the situation. As for me, as I said before, I’m not going to spend any more time massaging bits without changing them and expecting that to change the sound.
Also, I have the same question as @nquery: how is the predictability of the transfer between host and target capable of improving the D/A conversion timing when the target uses asynchronous USB to send the bits to a DAC that, in turn, uses its own buffers and its own clock to control the D/A process and to fine-tune the USB transfer rate according to the said own clock?
5 Likes
I’ve shared my findings and tuning guide with David, and he has created a test plan in his Github project. He was the logical person to validate my guide, and I’m looking forward it.
As for how Diretta impacts the DAC, Diretta moves real-time audio clock control and packet pacing away from the Host OS and into a tightly controlled Host→Target feedback loop, so the Host sends audio only when the Target explicitly requests it and at a cadence aligned to the DAC’s consumption. This eliminates OS-driven burstiness, network jitter accumulation, and buffer over/under-runs before USB or I²S ever reach the DAC. The result is a more time-stable, lower-noise data stream at the DAC interface, improving jitter behavior, phase coherence, and low-level detail during playback.
I agree that documentation is scarce and mostly community driven, with a lot of confusion, which is why I started documenting my findings into a guide.
2 Likes
-
The DAC clock remains the sole authority for audio conversion timing.
-
Diretta operates upstream of the DAC, controlling when audio data is delivered, not how the DAC clocks it out.
-
The Target observes buffer fill level and playback progress (derived from the DAC’s consumption rate via ALSA/USB feedback), then requests data from the Host at precisely paced intervals.
-
The Host sends packets only in response to these requests, preventing burst delivery, jitter accumulation, and OS scheduling noise from reaching the DAC input buffer.
-
Diretta does not reclock audio.
-
Diretta stabilizes data arrival timing so the DAC’s own clock works under optimal, low-stress conditions.
Think of Diretta as ensuring the DAC is always fed calm, evenly timed data, allowing the DAC’s internal clock and PLL to operate in their most linear, lowest-noise region—without ever touching the clock itself.
So @David_Snyder and others were, in fact, completely mistaken, it seems, but now may get to the true nirvana with additional guidance…
Alas, since the tests with RAAT and untweaked Diretta show DAC performance that has jitter and noise impacts well below hearing thresholds, it appears that high-quality DACs like the Topping D70 don’t care much about “calm, evenly timed data.”
EDIT: removed the d word since it appears to sometimes cross into moderation negativity!
3 Likes
So we agree that Diretta does nothing to improve conversion timing, so all talk about jitter is irrelevant.
If the data is not delivered properly and there are buffer over- or under-runs, the audio will simply glitch, so that’s obviously not the case, with or without Diretta.
That’s exactly what the DAC does with USB. The connection works at a steady, pre-negotiated rate, and the rate adjustments are ever so small. There’s no need to do that yet again at the network layer.
If any noise reaches the DAC’s input buffers, it’s a bad DAC. And even if that was the case, a simple isolator would do the job just fine, without any OS tweaks.
I have absolutely no idea what “clock stress” is. It’s a TCXO/OCXO/etc. running at a fixed frequency and having an extremely low jitter.
With async USB, there is no PLL. The clock runs at its own pace at all times, and if nothing touches it, then nothing stresses it or causes it to freak out or have a panic attack.
Everything you’ve said so far has been said many times already, one way or another, and I’m getting a little tired of responding to these successive waves of unproven claims and loose technical terms. If you want to convince me there’s any merit in these theories, you need to back them up with some kind of objective evidence, as I did when I debunked them.
9 Likes
Diretta manages the data flow over the Ethernet link between the Diretta host and the Diretta target. With a modern USB DAC supporting UAC-2 and async USB, it does absolutely nothing to change the data transfer pattern over the USB link to the DAC. With or without Diretta, the data transfer timing over Ethernet is only very loosely associated with the data transfer timing of that same data over the USB bus and that in turn is only very loosely associated with the timing of the delivery of samples to the digital to analogue conversion stage in a USB connected DAC.
I have already explained how the async USB audio data transfer works in my earlier post. I won’t do it again.
That USB protocol allows very little room for changing the USB data pattern (and what there is is likely determined by the USB protocol stack on the USB host end and the driver/abstraction layer that provides access to applications - e.g. ALSA. It is certainly not something that Diretta influences.
Connecting a DAC via USB to a Diretta target rather than a RAAT target (or any other streaming protocol) does not affect the nature and delivery pattern of data to the DAC and, as has been said multiple times before, the data delivery over USB has no relation to the timing of the clocking of the data onto the actual digital to analogue conversion stage within the DAC (which is the only point at which data delivery timing matters) other than the simple fact that the average data transport rate over USB must match the average data consumption rate by the analogue to digital converter.
You can argue that Diretta has an influence on processor activity patterns, power consumption patterns, network activity patterns etc in the Diretta target device and you can argue that it isolates the streamer (the Diretta target) from broadcast/multicast traffic on the network and the limited amount of extra processing that this involves (again - in the Diretta target device). However, you then have to explain how any of that can affect the performance of the DAC which is separate to the Diretta system and has already been designed to isolate the analogue performance from external influences (as is the case with any half-decent DAC).
Indeed. There is no technical reason why Diretta could not support both IPv4 and IPv6. I suspect that IPv6 is specified because it has mechanisms to automatically assign ip addresses without a DHCP server (which, following the Diretta logic, would be undesirable) and so it eliminates a network configuration stage - IPv4 would require both host and target to be assigned static ip addresses in a separate subnet to the main network by the user thus making system setup potentially more complicated.
In fact, IPv4 packets have a smaller header and so, following the Diretta logic, it would seem to me that it would be more desirable to use IPv4 because the amount of processing required to decode the packet header would be reduced.
7 Likes
Then the onus is firmly on you to demonstrate how it should be used. That is, put in the effort shown by both @David_Snyder and @Marian.
Until then, such claims are nothing but noise in this forum.
1 Like
That’s what buffers do, which sit between the transport and DAC. Irrespective of this, the DAC will always reclock. How do you think the duty cycle would be less noisy when data are sequentiall received from the buffer. At that moment, how the data are received is irrelwvant.
2 Likes
In my mind, the clocking/timing/jitter issue comes down to this - do you or do you not believe that Asynchronous USB Audio makes upstream clocking/timing irrelevant (aside from obviously audible issues like buffer under/overruns)?
If not, wouldn’t you be better served using a synchronous connection like SPDIF/I2S/etc along with PLL wherein the upstream device has much more control over data delivery and your tweaks are much more consequential?
2 Likes
Well, that’s exactly what David’s setup is doing 
I don’t see anything IPv6-related in his guide, so Diretta doesn’t require IPv6.
2 Likes
Fair enough. I never read the guide because I wasn’t interested. It was another post, above, that said it was IPv6 only.
2 Likes
No worries @Wade_Oram, I just wanted to show that you are absolutely right - as always - and correct the record.
3 Likes
This is a completely different question and will cause a different argument.
Asynchronous audio relies upon the quality of the clock within the DAC which should be both accurate and stable in any well designed DAC.
SPDIF and all other source clocked transports rely upon the quality of the clock within the source.
PLLs used to match the sample clock within the DAC to the data rate over the transport (dictated by the source) employ a servo which, almost by definition, means that they do not produce a perfect clock. Instead the PLL clock rate will vary very slightly as it oscillates around the correct frequency. This oscillation will be a very low frequency so, in audio terms, if it can be heard at all, it will probably manifest as very small pitch variations rather than a distortion. If the clock in the source is not stable as well the PLL will have to start chasing the source clock variations.
In general (and I accept that there will be exceptions), I would trust the DAC’s sample clock rather than the combination of a source clock and a PLL in the DAC - especially if the source is something like a Raspberry Pi with a basic digital audio HAT.
1 Like
Agreed, but the takeaway is that, should you be particlarly worried about certain drawbacks of certain connections, you have better choices than using two boxes instead of one and fillding with CPU isolation, interrupt affinities, subnets, IP forwarding, network power management and other tweaks that call for a degree in computer science.
Absolutely. I always advocate for using the good old async USB as the best bet for audio quality.
2 Likes
You don’t know me but I am a hobbiest that has used Roon for years. It’s excellent for navigation, meta data, ease of configuration, and support for Tidal and Qobuz. And RoonBridge is very easy to setup and integrate. For most users its job done. However, for a long time I’ve struggled with the overall sound quality. Hi-end SACD and RedBook players have sounded better in my system. I’ve believed that Roon should sound that good or better. For years people on the Roon forums have constantly pushed back on any alternatives with an “its bit perfect” slogan whenever an alternative is discussed.
I’ve tried other solutions than Roon/RAAT. They may have an edge but lose out on the excellent features in Roon. My problem is RAAT at the handoff to the DAC. If there was a way to significantly tune the Bridge system I would like to try it. That’s how I came to try Diretta. To be honest, it didn’t sound better than RAAT when first installed. Some settings made it better, others worse. Instead of abandoning it, I dug in to understand what it does, system impacts, and how to tune it.
I’ll provide an analogy – a carburetor. Off the shelf I can install one, and my motorcycle will run, but it will run the like crap. If I don’t understand the proper air/fuel mix and build the jetting stack correctly I will make it worse. Reading how it works and testing it I can dial it in so the engine purrs.
I have a sound tuning methodology that is repeatable, which is why I shared it with David so it can be peer reviewed. I tried to share the basic settings with Marian so he can try, as in my opinion he did not debunk Diretta but took an off the shelf carb and expected it to run well.
I’m not saying that what Marian tested was wrong, or the configuration steps from David are incorrect. They’re just incomplete due to the lack of any reliable documentation from Diretta.
2 Likes
I think there’s a fundamental mismatch here between what Diretta is designed to control and what was measured, which leads to conclusions that aren’t supported by the test itself.
Diretta is not a physical-layer noise reduction technology. It does not control USB PHY behavior, DAC power rails, internal DAC clocks, or analog output stages. It is a transport-side timing and scheduling system whose purpose is to control how and when audio frames are delivered over the network and buffered at the target. Expecting measurable changes in DAC power rail noise or static output spectra misunderstands its scope.
The measurements shown actually confirm something important: both RAAT and Diretta deliver bit-accurate audio to the DAC. Identical FFTs and output spectra are exactly what you would expect if both transports are functioning correctly. That result does not invalidate Diretta; it simply shows that Diretta does not alter the audio data itself — which it is not supposed to do.
Where the test falls short is that it does not measure any of the variables Diretta is designed to affect, such as:
- packet inter-arrival timing consistency
- host/target buffer fill and drain behavior
- scheduling jitter under load
- feedback timing stability
Static FFTs and power-rail noise measurements cannot reveal those properties.
There is also an implicit assumption that “larger buffers are always better,” which isn’t universally true. Large buffers trade timing precision for robustness. Diretta’s design intentionally explores the opposite trade-off: tighter feedback timing and more deterministic delivery, at the cost of requiring a more carefully controlled host and network environment. Whether that trade-off is worthwhile is a valid discussion — but dismissing it based solely on static output measurements misses the point of the architecture.
Finally, the conclusion that Diretta is “busted” goes well beyond what the data supports. The test demonstrates that:
- both transports deliver correct audio
- Diretta does not change DAC power rail noise
- no gross analog differences were observed
It does not demonstrate that Diretta fails at its intended purpose, because that purpose was never directly measured.
If the goal is to evaluate Diretta on its own terms, more relevant metrics would include packet timing histograms, buffer state logs, or scheduler/IRQ latency under controlled load. Without those, the test mostly confirms expected behavior rather than disproving the design.
In short: the measurements are valid, but the conclusions assume Diretta is trying to do something it was never designed to do.
2 Likes
Oh my Nietzsche! Into every gap they put their…
There is an extensive discussion of asynchronous USB above that invalidates most everything you just wrote. More, you need to brush up on how time and frequency domains interrelate.
Per my recommendation above, show rather than tell.
3 Likes