I wonder if it’s a cultural thing…something being lost in translation.
I’ve found that most Roon subscribers blissfully ignore Roon Lab’s sound quality recommendations too.
Reference: https://help.roonlabs.com/portal/en/kb/articles/sound-quality
Some of that certainly is (Japanese, and East Asian in general, web sites, unless specifically designed for the occidental audience, do look quite different). But But we’re not talking look&feel or style, but rather quite technical claims. Those generally tend to be fine, even if sometimes badly translated. Diretta’s though, “there’s no ‘there’ there.” As far as even attempting to present some kind of realistically looking problem and a proposed realistic solution, it makes as much sense as the “technical white papers” you could find with manufacturers of directional audiophile fuses, green markers, and CD demagnetizers.
A good chunk of Roon’s market is audiophiles, and they aren’t going to alienate them too much. Besides, from the support perspective it is always to overspec than underspec.
That’s a rather conspiratorial interpretation of Roon Lab’s recommendations for sound quality. Not the first (or even fifth) time I’ve read something like this before in this community. 
Or, perhaps those music lovers, who don’t sweat it, and simply carry on enjoying the music are having all the fun.
5 Likes
David: would the test (I’m presuming disconnecting the Roon Server from the network and letting the Roon Ready client send its buffer to the DAC) removes the issue of the bursty Ethernet process causing problems on the receiving client? I recall that the issue is allied with using gigabit speeds versus megabit speeds for audio-based data transfers. If true, it would call attention to how well the client is designed to “handle” the Ethernet bit transfer activity, especially for the high bitrate source material.
Not meaning to be pedantic, but the DAC controls timing, and will empty its buffer. Roon Bridge has very little buffer, and again what is requested over the network is also controlled by the DAC. Nothing is sent, its pulled.
Indeed, I suspect RAAT works in a similar way to what Diretta aludes to, i.e., there is no burst of data or sending the entire track in one go. However, if the DAC says, “send me 45 seconds of the stream”, I don’t see how Diretta could possibly change this. If it did, it would almost certainly cause issues with playback, especially on a Wi-Fi connected endpoint.
I think unplugging the network cable from the endpoint device is a better test. This eliminates the possibility that network traffic unrelated to streaming audio is contributing to the negative effect.
When I suggest users try this, I recommend that the copy few complete tracks in uncompressed format (WAV or AIFF) to /tmp on the endpoint device. This file system is usually mapped to system memory, so accessing it does not generate I/O requests to the boot drive. I then have them kick off playback of one or more tracks in the background just before pulling the network cable.
If network traffic was causing a problem before, taking these steps will eliminate it and should not add any new problems. What’s not clear to me is if this local playback scheme produces a smoother CPU and power supply noise signature than Diretta’s evenly spaced tiny packet delivery. I could see this going either way. Without taking objective measurements for a specific operating system and device, it’s anyone’s guess. And the effect, if there is any, is likely to be highly dependent on the DAC.
Yet it is very easy to determine that a RPi running Roon Bridge is all but idle while streaming.
Overall, I think this is clutching at straws, and such miniscule fluctuations are irrelevent in terms of interference in the DAC, and absolutely meaningless in the digital domain.
If you really think that Diretta has made a noticable difference to what you hear, then you could look for rational reasons. Is it transforming the stream in some way? Maybe an increase in volume or applying some filter? Maybe capture, analyze, and compare streams?
1 Like
Doing a packet capture of the stream over the network (e.g. using tcptump) might be messy since I don’t have a way to decode the Diretta protocol. However, I may be able to record the digital audio from the USB port on the Diretta Target computer using my Topping Pro E2x2 OTG audio interface. The OTG digital input is limited to 24-bits, 48 kHz, but content with that sampling rate is not difficult to find and I can always have Roon Server resample.
If my E2x2 OTG supports UAC2 USB sources (I’ve never tried), I should be able to record digital audio from a Raspberry Pi running Roon Bridge with no Diretta and the same track again from the USB port on the Diretta Target. To make sure my methodology is good, I’ll make two or three recordings of the same track from the non-Diretta RPi and confirm that the samples match before proceeding.
I can use SoX or ffmpeg command-line tools to compare PCM samples. If there’s any funny business going on in Diretta, as you suggest, I won’t be able to find any sequences of samples that match. I’ll report back.
I was thinking about the PCM stream sent to the DAC by Diretta. Then compare the same track using Roon.
1 Like
Where would I capture this stream besides at the USB output of the Diretta Target computer? How can Roon be used to compare tracks?
Sorry, I’m not following.
I was thinking that you could use a test signal, pass this through each protocol to analyze each output, and then compare. They should be identical.
You’d achieve this using the analogue signal from the DAC or a dummy audio device.
Recording the analog output from the DAC while using a Diretta vs non-Diretta transport could be interesting also, but I’d have to use spectral analysis and other higher-level tools to compare the recordings. While that still might be interesting, the lower-order bits of the PCM samples in an analog recording would include random noise, making bit-for-bit comparison imposible.
The definitive comparison will be from captures of raw PCM samples leaving the digital (USB) outputs of each transport. I think I’ve worked out a reliable way to do this. Will play around with it over the next few days and let you know.
Edit: I should mention my hypothesis is that a comparison of the PCM samples leaving the USB ports of a Diretta Target will be identical to those from a standard Raspberry Pi running Roon Bridge. Further, both should match the PCM samples in the source file since Roon’s R.A.A.T. protocol supports bit-perfect delivery.
However, for Diretta’s claims to be true, the analog output of the DAC must be different when Diretta is in use. I don’t know if I possess the tools and techniques required to objectively reveal and quantify such differences in a reliable, repeatable manner. If I decide to attempt this, I’ll share my procedure and the results.
1 Like
Honestly, IMHO this is getting ridiculous… If it were providing different output on the USB port, it’d be an outright fraud, so we can probably discount that.
So we are supposed to believe that there would be enough different/stronger/extra analog noise passing from the network adapter in the bridge, going through that system, coming out of the USB port, getting into the DAC and affecting its performance in an audible way?
It is highly unlikely that there’s anything measurably different on the USB output (measuring analog signal, of course) with or without Diretta. But if whatever might be there really were affecting the DAC, one probably should start with making sure that all the microwaves are disconnected, nobody is passing down the block while using a Bluetooth headset, and the neighbor across the street isn’t turning any CFL lightbulbs on.
If Diretta made any real difference, developers would be shouting about it from the rooftops. So far they still haven’t come up with anything better than a nonsensical whitepaper that might just as well talk about phlogiston.
Isn’t this what bypass capacitors are for? They are placed at the vcc input of integrated circuits specifically to compensate for bursts of current draw. The capacitors act as a “local” reservoir of power, so as to reduce voltage drops. A capacitor across the power inputs would also serve as a filter for noise.
1 Like
This, yes. But, many DACs use galvanic isolation/digital isolators, and use separate power supplies for USB subsystem, DAC, and, depending on DAC architecture, analogue stage, etc. What happens downstream should not affect a well-designed and implemented DAC.
1 Like
It is included in the SOtM sMS-200 streamers, and justify itself pretty obviously, once implemented.
The japanese engineers and designers have a similar issue with the intermittent transfer of async data over USB Audio as well, and have created a protocol for that also, BulkPET…
I have tried this on the Soulnote D-2, a very nice DAC in it’s own right. Issue with BulkPET is that more or less demands you use a standard PC as server, which will not be to everyones taste.
And honestly, i didn’t experience much difference from the default async transfer method in my setup, but i did find a preference for BulkPET over asynchrous transfers.
1 Like
Diretta’s example demo graphs for their “improved” stream made me look at my own network, which is comprised of daisy chained Ethernet switches. Here’s a graph of a downlink to the switch where my Pi endpoint is, nothing but RAAT. They look cleaner than the demo graph on Diretta”s website.
Thinking about this over the weekend amused me. I’m glad I don’t have the type of ears or brain that can make these claimed distinctions, otherwise I’d probably never be satisfied with my system.
1 Like
Interesting…that can’t be good for latency? What problem were you attempting to solve by daisy-chaining switches?
Another non-solution for another non-problem.
2 Likes