Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
1
Does anyone know of any hobbyist testing the bit-perfect accuracy of streamers? By that I mean comparing the bits that appear on the output of the streamer, either via S/PDIF or USB Audio, with the source bits, assuming no DSP or other manipulation of the sound. We seem to all kind of assume they are bit-perfect, but it would be good to test this hypothesis.
It would be tough to do for a Roon Bridge streamer, as the format of the Roon network packets isn’t documented (or am I wrong about that?), so you don’t know what bits are going into the streamer, but you could compare against the original digital source file.
At the “hobbyist” level of testing, have Roon (in a bit perfect configuration) play a DTS CD rip to a network endpoint. Connect the network endpoint to an AV receiver or processor. If DTS decodes without a hitch, the stream and streamer are bit perfect.
Hi Bill, do you have a particular streamer/s in mind?
And with which DAC?
If it’s Roon Tested and Roon Ready gear you can safely bet that the Roon Team have checked this.
If it’s not RT or RR, you can still trust Roon’s bit perfect signal chsin status.
But a good way to verify is playing DSD over PCM (DoP) which is why I asked about which streamer/s and DAC. You will know if playback is not bitperfect with very obvious audible dropouts…
And another good bitperfect test is MQA if you have an MQA DAC (renderer or full decoder).
Do you know of anyone doing this and publishing his results, in the fashion of Archimago and Amir?
Well, I probably would, but trusting and verifying are two different things. For instance, bad driver implementations on a streamer can drop output packets or input packets. Nothing to do with Roon’s software.
A Pi running RoPieee is Roon Ready, I suppose – is it also Roon Tested?
Yes. But I see tests of the various DACs, just assuming the streamer is producing the expected bits. Must mean the testers don’t think the fidelity of the streamer is worth testing.
The Roon Team would test all that if the streamer is Roon Ready… They are just as obsessed as anyone, with checking bitperfect output of streamers before they certify it ‘Roon Ready’.
But there’s a few ways to verify yourself too.
I don’t think the Pi is Roon Ready… it is RAAT bitperfect capable for sure though.
Noted but the beauty is you don’t need them to do these tests… If you speak to your DAC designer they will likely tell your the DSD over PCM test is quite good (if your DAC supports DoP) to test the source/upstream chain… as mentioned before, you will know if playback isn’t bitperfect in the form of very audible dropouts. You don’t need Archi or Amir to confirm those audible dropouts fortunately.
Agree. However, some people may perhaps worry that a streamer applies its own DSP or upsampling in an attempt to make something sound better than original - that’s a hypothetical case as I don’t know of any streamers that do it by default, except for those products marketed as upsamplers.
Also agree to the above posts that DTS and MQA are great ways to verify bit perfect delivery.
1 Like
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
8
Maybe so, but independent verification is always a good idea. I’m just wondering if anyone is doing this already.
My main system is a Mytek Liberty fed by a RoPieee box, but I have a number of Chromecast variants scattered around the house, including a CCA, Insignia Voice, and Minis in every room.
Noted but if we are talking about DoP64 playback for example, then your DAC won’t indicate DSD (if it has an indicator) if the source is applying DSP to the DoP64 track… the DAC will likely indicate PCM incoming… or if the chain upstream of the DAC is affecting bitperfect playback, then you will definitely hear it with DoP with very audible dropouts (as mentioned before…).
Unless the streamer is secretly doing DSP to incoming DSD and still outputting DoP to the DAC… the chances of a streamer itself doing this though…? Possible but…
Noted. You can do this yourself with your MQA Mytek DAC
If you see the blue light (or MQA indicator), your chain up to the DAC is bitperfect. It needs to be for the blue light / indicator to come on. This is a requirement of MQA itself.
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
11
Um, well, I don’t particularly want to go into this business myself. I want to read the internets and find the results posted by some other poor devil. I don’t want to know how to do it so much as who’s doing it.
But even if you see the blue light once, it doesn’t really mean much, does it? My RoPieee reboots every morning, and each reboot can potentially introduce a new software load which could change things. And since I avoid MQA (no real reason except that it seems unnecessary) I wouldn’t verify it very often.
Because they are testing DACs not streamer, of course streamer matters. Stock RPi board already have USB port, but many products based on RPi add special HAT with USB, why? All of them including stock RPi can light up MQA LED on USB DAC means they are all bit-perfect. But they may not all sound equally.
Last century we already can send bit-perfect contents using Windows 98, but this is just the beginning to improve the digital music.
Hi Peter @wklie, I should also add one more thing.
If I was like the OP and had the wonderful Mytek Liberty DAC fed via USB running RoPieee but I didn’t want to touch MQA for a quick test (for whatever reasons and that’s ok of course)…
…then if I obtained free DSD sample tracks from http://www.2l.no/hires/ and Roon’s signal path was telling me the RPi was outputting DoP bitperfectly and the Mytek DAC was indicating incoming DoP at the same sample rate, and I heard no audible dropouts or pops/ticks after playing all those free DSD samples… then I could sleep very easy knowing the chain feeding the DAC’s USB input was bitperfect capable…
I’m quite confident even Michal himself (Mytek designer) would agree there’d be nothing to worry about after doing this test… but he’s quite easy to reach by email or phone…
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
15
Thanks again, @dabassgoesboomboom, but I’m not worried about my data stream or DAC (which by the way sounds great, though I am intrigued by the upcoming Burson Swing). I really am thinking about the state of equipment review, and making lists of tests that could be done on components. I’d expect this test to almost never reveal a difference.
Well, they don’t “sound” at all, I think. The sound is created in the fiendishly complicated and distortion prone analog world.
Yes, functionally DoP also serves this need of verification. However, it will have to go through DSD source music -> DoP -> DSD conversion. So one needs to accept this internal conversion happens without invalidating the result.
By the way, Roon does not support DoP in a source file. I actually made that as a request to Brian but this is not going to happen.
Noted. Agree it’s not the absolute perfect verification but it’s a reasonably good ‘quick and dirty’ one. Especially as in the case above where someone doesn’t want to try the MQA test (or doesn’t have an MQA DAC) it can be better than nothing. The DTS test obviously very good too, if one has access to DTS tracks.
In the past whenever I’ve tried a new source or changed anything upstream of my DAC, the first thing I try is DoP64 tracks over TOSlink and DoP256 tracks over USB (free DSD64 and DSD256 samples from 2L).
Interesting. Only some devices support DoP64 over Toslink (e.g. some newer Esoteric, Mytek, Chord), and even fewer support DoP256 over USB (e.g. Chord).
Even the Pro-Ject S2 DAC I’ve given to my old man (dad) supports both… Probably more common than you think?
Finding a source & optical cable capable of supporting DoP64 is more difficult than finding a DAC that supports DoP64 via TOSLink… That’s where this test is great as a ‘quick and dirty’ test. Many sources & optical cables have failed me with that test.
