Please remember to talk about the ideas, not each other. No one wants to read opinions about other users.
If you work for MegaTech, you might want to indicate that somewhereâŠ
Thatâs because thatâs how it is in the real world where we obey laws of physics.
You probably should⊠Since I am also completely unaware of the importance of unicorn rainbows, phases of the moon, and virgin sacrifices in the D/A conversion process, you probably should refrain from discussing those as well.
Any half-decent DAC made in the past 20 years or so has a clock, reclocks the signal, and is not dependent on the source timing. Diretta arranging packets slightly differently does not affect it in any way.
You may believe anything you want. Laws of physics and rather basic math do not care for beliefs though. And they dictate that Direttaâs uniform signal has no effect on DAC power consumption or jitter. If you have any proof to the contrary (MegaTech does not present any) you should post it, instead of network utilization graphs that tell that Diretta is chattier than RAAT (so likely less efficient) but nothing else.
I can actually conceive of an intentionally broken streamer that would work somewhat better with DIretta. But that would take some extremely creative design, and anything broken that much would not work very well with DIretta either.
I apologize to everyone for any inappropriate words or comments.
Why would a binary equivalent signal affect the sound quality in a digital reproduction system?
Since you mentioned the laws of physics and basic mathematics, I did a simple thought experiment to see what I could come up with as one of the factors.
I have tried to put numbers on it, but it is not a technically correct example. I have tried to be more specific than phases of the moon or virgin sacrifices.
The purpose is only to share an image, so welcome your frank opinions and rebuttals.
Let the voltage level of the clock signal be a standard 3V in TTL. Let the rise (fall) time of the signal be 350 ps (1 GHz in bandwidth).
Assume an ideal clock with zero jitter.
The reference point for the time axis is the midpoint between the H- and L-levels, i.e., the point where 1.5 V is cut off.
Assume that the jitter allowed for high-quality music playing is less than 1 picosecond.
In this case, the allowed threshold voltage error is ±3.5mV.
If the clock signal level is LVDS, the value will be an order of magnitude smaller.
This level of voltage noise could easily be caused by an input signal, if a noisy signal comes into the DAC, or if the processing load on the interface board within the DAC fluctuates too much, it could upset the ground level, power lines, and of course the threshold potential, leading to jitter degradation, or SQ degradation.
Again, the above is not a strict or correct argument. It is only intended to give an idea of the importance of the analog quality of the binary signal input to the DAC stage.
In the context of digital transmission and digital signal processing, error-free or at least bit-perfect will be achieved whether the H-level goes to 2V or the L-level approaches 1V.
In digital audio, noise levels three orders of magnitude lower than the signal level generated or introduced into the DAC can affect the clock jitter that determines the sound quality. In this way, the benefits of Diretta make sense, as well as the upstream effects of switching hubs, power supplies, LAN cables, and so on.
Compared to RAAT, Diretta is slightly less efficient in transmission, but we are only concerned with top-level fluctuations of 10% or so. Direttaâs use of the simple UDP protocol is also appreciated.
*I believe there is an explanation on the MSB Technologys website regarding âSQ degradation due to non-harmonic distortionâ caused by jitter on the order of sub-picoseconds.
*And I am not an employee of MegaTech. But I have actually used Diretta for over 2 years. Prior to that, I denied Diretta for a year without even listening to it.
And in my personal opinion, I think the following configuration is the best at this point
Roon Server â RAAT Server/Diretta host â Diretta target/I2S â DAC
Anything that operates above Ethernet is packet based at the Ethernet level and the time between packets is much greater than 350ps. Therefore:
- each packet contains data that represent time much greater than n-ps.
- the recieving device must buffer that data and then emit it based on itâs own clock.
- but it doesnât do this, because itâs outputting the same data via USB to the DAC, which is also packet based
- again packets of data are sent via USB and again time between packets is much greater than n-ps
- so the receiver of this data (the DAC) must buffer this data and process it from itâs own internal clock
Diretta is only involved with the Ethernet portion of this. How does any difference in the timing of packets on Ethernet affect the timing of packets of USB and consequently affect the timing of samples, buffered by the DAC and processed based on itâs internal clock?
How does reducing payload size and increasing number of packets in Ethernet (which will cause the receiver to do more work!) have any effect on the USB conversation that would be deleterious to the DAC which must already be capable of handling USB traffic from all sorts of excellent and awful sources?
How can you say that whatever happens at the Ethernet part of the chain is always beneficial regardless of DAC? I can imagine DACs that are very good at buffering and clocking and some that are not. I expect now in 2023, even inexpensive DACs are good enough at this.
I could probably think of other questions that have not been answered by you or any of the (sparse) literature regarding details of Diretta. Trying and testing something new costs time and money, Iâm not willing to engage without some logical explanation as to how this can possibly make a difference.
The 350ps rise time is taken from the maximum master clock frequency of about 98MHz when using the ES9038PRO in sync mode, which gives the best sound quality.
This figure is used to estimate the effect of voltage noise level on clock jitter, and has nothing to do with Ethernet-level packet cycle times.
Although Diretta/USB bridge is by far the most common implementation of Diretta these days, it was originally launched as a technology to convert network players into LAN DACs. My system is the same concept.
The I2S signal is generated directly from the incoming Diretta signal and sent to the DAC process. There is no buffering process.
Diretta is basically peer-to-peer transmission, and packet transmission is controlled synchronously with the Host side to keep the processing load on the Target side constant.
The packet transmission cycle can be adjusted by the settings, but 650 to 1000 packets/second gave good results in terms of sound quality. The average transmission rate is about 6.5 Mbps. The packet size is 1250 bytes.
For a 24/96 x 2ch music signal, the rate is 4.6Mbps, so the efficiency is about 70%.
This means that packet de-encapsulation and I2S signal generation can be achieved with a small load fluctuation.
Since the I2S generation takes place in the immediate vicinity of the DA element and clock generator, I imagine that large load fluctuations in this process, along with changes in heat generation, could be a factor in clock jitter.
I am not able to answer your question because I do not understand the details of isochronous USB transmission.The fact is that the Diretta USB Bridge also improves SQ. So I imagine that the load on the USB transmitter side is constant and the buffer usage of the DAC is kept at a constant level, so the process load fluctuation in the DAC is also smaller.
Of course, clocking performance may vary from DAC to DAC. I just think that a uniform USB stream is better for all DACs.
The implementation of Diretta is a hurdle, and I do not strongly recommend it.
But rather than dismissing this technology out of hand, I encourage you to audition it yourself if you have the opportunity.
Thanks,
There is always a buffer somewhere. Every network card has them to begin with
Iâve been interested in Diretta for a while and like the OP I would like to try it in Roon. The reason I hadnât so far was because the compromises I had to make to run it (moving away from ROCK to Windows or Gentoo) detracted from the Roon experience for me. The ideal situation would be for Roon to make ROCK a Diretta source and, where the OP is concerned for Sonicorbiter to do the same. I strongly suspect Roon wonât make a move in that direction because they wonât invest the time to see if the principle works as advertised. RAAT is their chosen direction and they are entitled to stick with it. Doesnât stop me being curious though. Roon is presently running on a lightweight Windows 10 installation and I am waiting for an opportunity to build a decent Diretta endpoint. It doesnât actually cost anything to try except time.
My apologies.
You are correct. It was my mistranslation.
I found the following statement in Direttaâs technical documentationïŒ
Diretta does not adjust buffers or data flow.
I agree with your view on the direction of Roon.
If you have Windows PC ready for Roon core, it is easy to implement Diretta. As you say, the cost is also affordable.
You can build the system with Roon core/diretta host on Windows first, and if you like it, you can make NUC as Roon core and Windows PC as Roon bridge/Diretta host. Separation of Roon server and RAAT server is Roon Labâs recommendation, and in fact improves SQ.
FYI. This is my cheap setup for Diretta between Roon(ROCK) and my main audio system. It is enough simple and cost effective to start. I havenât change any of Roon side. Note that I donât use i2s out that will be for the future. Also the fiber link is not mandatory to put between.
My additional investment area is mainly the follwing two:
- Celeron based Linux server for âRAAT-Direttaâ Bridge (Roon Bridge/Diretta Host)
- RaspberryPi4 for Diretta Target and/or Roon Bridge on GentooPlayer.
For clarification, the rationale for decentralisation and using separate end points are described in these help centre articles.
And eventually the samples end up in the DACâs input buffer and they are there when they are needed or they are not. Jitter and packet order on the network before this point have no influence on this
Looks like by the time I woke up this has been debunked well enoughâŠ
Could we still stick to a single fantastical claim at a time?
As noted multiple times already, in any realistic equipment configuration, with multiple levels of hardware and software buffers between the Ethernet jack and DAC input (and most likely some buffers in the DAC as well), there will be no timing differences at decode. That Diretta even makes this claim is already a good indication of snake oil.
As for electrical noise, I suppose these claims mean that Diretta is absolutely useless in a WiFi setup? But even in a wired setup, any claimed advantages would depend on a) the shape of electrical noise at the network interface being materially different due to protocol differences (nope, it wonât), b) that this noise actually filters down all the way to the DAC (even an external USB DAC or somesuch), which isnât the case except for something broken by design, and c) that those differences would actually be audible, let alone beneficial in one direction or another, which does not appear to be the case either.
Thereâs nothing per se wrong with Diretta (apart from being a solution in desperate search for a problem) â if you already have a setup that supports it, it will work as well as anything else.
I see
Ohm I see. Audiophile network cables⊠So you do believe in pixie dust!
You havenât debunked anything. Just argued against it! To debunk it you have to try it and prove it doesnât work! If you choose not to use it based on your reasoning (which I will add is not unreasonable) that is OK. But that isnât debunking anything!
The claim that there is no buffering when using Diretta was
Sorry, but n ope. Thatâs not how it works.
Diretta makes certain claims about why their protocol is advantageous. The timing claim has been thoroughly debunked. It is literally contrary to how computer networking (and thatâs all it is) works. Itâs contrary to modern DAC inner works, too, but I guess you could find some $100K boutique audiophile DAC that has no internal buffering or clock and relies on the source.
This really should be enough to dismiss it as snake oil.
Diretta also makes a claim about allegedly lower noise somewhere when using their protocol, but it is actually up to them to demonstrate that this is the case, as there are no electronic reasons for it to be so. There are very good electronic reasons for it to not matter, but Diretta shows no proof of that. Or anything else. They just have a couple of meaningless graphs that literally do not show anything useful.
If one is an âaudiophileâ of the âfuses make a difference!â persuasion, then sure, one may chose to believe whatever BS Diretta is saying. If one is even vaguely familiar with how electricity flows and packet networks work, then it does not even need much debunking.
Itâs like demanding that somebody debunk FraudioQuest Ethernet cables for youâŠ
We have discussed diretta previously on the Forum, enough so that I feel confident thereâs nothing to it.
Allow me to explain why I feel that way.
If you look at the Diretta page put up by MegaTech Electoronics LLC [sic], youâll see that the âmagicâ lies not in the protocol, but in the DAC, which is optimized to reduce fluctuation in power consumption:
There is only one way to achieve this goal: averaging of processing and reduction of fluctuations in power consumption.
You have to build a DAC that can maintain a constant level of current draw while itâs operating, a difficult thing to do with most music. They call the DAC the âTargetâ (âa player with an analog part is the Targetâ):
With regard to the Target, processing is minimized and simplified to enable averaging. The Target is configured by means of simple processing, like hardware processing by FPGA.
The reason for the network protocol is to try to help the DAC with its constant current struggle:
Packets are transmitted as often as possible at constant short intervals in order to average processing.
Apparently with no flow control. The Host is supposed to use âforecastingâ to predict buffer availability in the DAC. âForecastingâ is another word for âguessingâ.
Iâm no electoronics expert, but you apparently need a specially designed and built DAC, not chip-based because chips are little computers with their own software which you canât fix, to start with.
But you also have to buy into this idea that power fluctuations in the analog circuitry of the DAC will result in noise, which is completely bogus. And then you feed the analog output of the DAC into an amp â is that going to be constant current as well? If not, wonât there be more noise generated by power fluctuation?
So the very thesis of Diretta is pointless from an SQ point of view. Maybe someone built it into some gear in a desperate attempt at product differentiation? You know these manufacturers like to sell us more gear!
Agreed.
But what happens if a dirty signal or a signal with large load variations comes into that bufferïŒor DAC)?
Even if it doesnât break the logic, it will dirty the ground and power lines of the DACâs electronics board.
It would seem that such a small noise would not affect the SQ.
But what if the timing clock fractions on the order of femtoseconds or picoseconds affect the SQ?
This is my argument point.
Pixie dustïŒ
I donât know what that is, but I have experienced that LAN cables can change the sound.
I am not saying that expensive cables are better. I am saying that I have experienced that some affordable cables can greatly improve the sound.
Nobody is asking you to do anything though. I know you feel you have to step in and debunk things verbally. But you really donât have to! Neither do you need to explain electrical theory to anyone. Least of all me! I will try Diretta. I will make my own mind up. Iâll report back for anyone interested. Iâll be honest. If it does nothing I will say so.
For the record, there are no fancy cables in my system. Or fuses. Iâm not sure why you quote those when this is about something else.