Alternatively, you could’ve also used Audacity…
To do that, you need to have a Raspberry based streamer that runs GentooPlayer or AudioLinux.
If you have a PC, you install a Diretta ASIO driver on your computer. This driver transforms the PC into a Diretta Host.
You select this driver as an endpoint in Roon, just like selecting a DAC that is attached to the USB port of your PC. Roon outputs the sound to the Diretta ASIO driver, and the driver streams it over the LAN with the Diretta protocol to the RPI based streamer. The RPI streamer needs to be configured as a Diretta Target.
You can use Diretta with Roon Server on a computer that runs GentooPlayer or AudioLinux. In this case, the computer is configured in GentooPlayer as a Diretta Host, and it streams the sound to the RPI based streamer that is configured as a Diretta Target.
Actually, it is possible to use Roon with Diretta on any other Linux distribution, like Unbutu, for instance. For that, you need some practice of Linux in order to know how to implement the ALSA drivers of Diretta in Unbutu. Then, you’ll stream with Roon from this computer to your RPI based streamer that is configured as a Diretta Target.
If you use Roon with a Mac, you need an additional computer on your LAN. This computer should run GentooPlayer or AudioLinux, and should be configured as a Diretta Host. Roon will stream from the Mac to the Diretta Host with RAAT, then the Host will process the sounds and will stream it with the Diretta protocol to the RPI based streamer (that is configured as a Diretta Target).
It seems settling up a turntable, arm and cartridge is simpler than all this digital nonsense. Glad I stuck with it, I have to say I don’t find ROON this complicated either though. Is it a trait to tinker to the point of insanity?
All that to send bits over a network? We’ve moved from noise over Ethernet to timing over Ethernet. This is going for the worse.
If you use Roon on a Windows PC, it’s not more difficult than installing an ASIO driver of a DAC.
But if you are not comfortable with Linux distributions, it’s not for you.
However, it seems that in Japan, there are already some commercial streamers that are sold with the Diretta software, already installed on their OS.
If you are happy with an out-of-the-box solution, it’s perfectly understandable, and it’s fine.
But you should be aware that there are options to improve further the sound of your system, if you spend some time to learn about them. And they cost very little.
I found the website: https://www.diretta.link/ Apparently MegaTech Electronics, from Tokyo.
It looks like their core philosophy is that power usage fluctations can cause noise. So they aim to reduce that fluctuation, in the endpoint.
Please suppose that a player with an analog part is the Target
So you need to have a Diretta-native player. Looks like several manufacturers have models that are that.
It is similar to USB synchronization, but the Target doesnt change speed because the Host synchronizes.
Isn’t this what USB Audio Class 2 supports? That is, the endpoint can send feedback to the host to adjust its sending rate.
I don’t see any experimental data. Looks more like a thought experiment without validation.
Unless you use DSP, there’s nothing that can be done the digital domain regarding SQ. As far as real-time data protocols go, they either work or you get dropouts. I’ve spent a lot of time learning this stuff, not just some. The more time I spend, the more ridiculous I find these claims to be.
Sort of. The theory of Diretta is apparently derived from the old idea about “computation causes noise”, which has never been shown to be true. But slightly different: “varying rates of computation cause noise; constant rates lessen that effect.” So it’s really about maintaining a constant rate of computation, or constant current flow, in the endpoint, and varying network speeds in order to make that happen (even though you can’t really make that happen by varying network speeds, I’d think).
I’d like to see some evidence of both the planted axiom (that computation causes audible noise in the analog output), and the supposition therefrom (that constant levels of computation can lessen said noise). Without evidence for either, I think Diretta has to be placed in “probably just another wild theory” category. For now. Perhaps someone will actually run some tests.
Diretta is beneficial both for reducing the CPU load of the Target, and for reducing time domain errors.
Unfortunately, there’s no documentation in English about this new technology. What we know about it is from a group of French friends who participated during two years in its beta testing, and who often exchanged then with the Japanese developers.
On the contrary, much can be done, and there are additional options to reduce time domain errors.
10 mHz reference master clocking improves the performance of devices of the setup, and synchronizes them, reducing further time domain errors, and improving spectacularly the SQ.
Are you sure or have you done it with statistical significance (8 out of 10 in one try is not statistical significance)
My method of testing it was a perfect A/B comparison.
I connected two streamers that sound almost the same to a Digital interface that is connected to the DAC. Both run the same version of GentooPlayer, and were configured as a Diretta Target.
One streamer was connected to the DIY switch (that sounds exactly the same as EtherRegen). The other to EtherRegen that was connected to the 10 mHz reference clock.
I streamed with Roon the same track to the two streamers, like two endpoints, and I switched during the playback between them with the output selector of the Digital Interface.
The A/B comparison was in real time, the difference between the playbacks of the same track was immediately distinguishable.
@Dandou, network interface clocks have no bearing on the timing accuracy of D/A conversion. The latter depends mainly on the DAC’s internal clock and, in some cases (e.g. S/PDIF), to a much lesser extent, on the input type. In case of “async USB”, only the DAC’s clock matters.
Regardless, I couldn’t find any reference to “time”, “timing” or “clock” on Diretta’s home page, so I’m not sure how “time domain errors” are relevant here.
Great! Let’s record the electrical outputs, or even the sound, with a microphone, so that others can see that difference, as well. That (and documentation of the test set-up, of course) is really all that’s necessary to convince all these doubting Thomases.
I don’t find this convincing at all but am taking my leave from this thread
Asynchronous USB connection reduces time domain errors in USB tranfers. Diretta does something similar in network streaming. The short page in English just does not speak about it. But their site is not the only available source of knowledge about this technology. There is much more about it on French audiophile forums.
As I said, a group of French audiophiles participated during two years in the beta testing of Diretta. They chat then often with the Japanese developers. And they have a good understanding of this technology.
Regarding network clocks, they do matter. The clock of the DAC is the master in USB transfer, but very few DACs have the best clocks. With master clocking, you reach much the best results, especially if the transfer to the DAC is through I2S.
That’s an A/B comparison alright, but since it’s sighted, it does nothing to eliminate bias (unconscious or otherwise), so I have no idea what makes it “perfect”.
Sometimes, the difference is subtle (like the difference between the two Netgear switches). But in this case, the difference was a sensitive one, and it was obvious.
Anyway, this test does not mean that the sound improvement forcefully resulted from a better performance of EtherRegen. It’s possible that the improvement was due to its synchronization with the other devices of the setup that were connected to the same master clock.
That’s not what it does. It just makes sure that the internal receive buffers don’t overflow or underflow. If the USB rate is a bit too high compared to the D/A conversion rate, it is slowed down, and if it’s a bit too low, it is sped up. The D/A conversion rate depends solely on the DAC’s clock.
Given the above description of how async USB works, it should be clear that the timing of network streaming is not relevant as long as the overall transfer rate is maintained such that the D/A conversion buffers don’t overflow or underflow.
Using I2S simply bypasses the DAC’s internal clock and buffering. Everything else stays the same, it’s just done outside of the DAC instead of under its chassis.
The main purpose is to prevent long-term problems due to the inevitable slight differences between the clock frequencies on the host and that on the target device. Without feedback, these errors would eventually result in the buffer on the target device emptying or over-filling. Using asynchronous mode with feedback allows the target device to “control the clock” insofar as it can clock data to the DAC driven by the local, presumably accurate sample clock. It does not affect short-term timing which is driven by the number of samples the host chooses to transfer per USB frame period. Unless the audio sample rate is an exact multiple of the USB frame rate (8 kHz) the number of samples per frame will not be constant so there will inevitably be short term timing fluctuations; the asynchronous feedback does not change that. (Which of course is why there has to be a buffer to de-coupling the USB bus from the DAC.) What the feedback does do is cause the host to occasionally insert an extra sample or remove a sample to prevent long-term drift from accumulating.