I am new to Roon community. I am just starting and getting experience. I discovered a strange thing in my Roon setup. The tracks are not played bit perfect. Here is the setup.
The DAC is MSB Select II DAC. The RAAT device is dCS Network Bridge. Both are connected together with 2 cables : AES/EBU for data and BNC for clock. The MSB dac provides reference clock to the dCS Bridge and received music data by AES/EBY cable.
The dCS bridge serves 2 protocols RAAT and DLNA/UPNP. The roon core and J.River Mediacenter are installed on the same MAC notebook. The MediaCenter is acting as DLNA/UPNP server for dCS Network Bridge.
The MSB publish special BitPerfect tracks to diagnose if their DACs play tracks bitperfect. Only MSB DACS understand those tracks of course, they display BITPERFECT PASS if the MSB provided test track is being played bitperfect. When I play the MSB test track from MacBook with J.River to dCS Network Bridge, (actually I choose the track using dCS provided application) the track is being identified on MSB DAC as bit perfect. Doing the same from ROON thru the same hardware that is : dCS Network Bridge to MSB DAC, the Select II DAC reports that the track was not played bit perfect.This is not related to frequency, each test track fails on ROON/RAAT with dCS.
The problem might be in dCS Network Bridge RAAT protocol implementation or may be in the Roon itself. I am not expecting you to solve this issue, just reporting something interesting and important, which may (I hope) have positive influence in playback quality in the future.
Let me know if anything comes to you mind in this regard. Maybe this is known issue ?
Please do post a screen shot of your signal path when Roon is playing one of these tracks. Also please post a shot of the audio device setup screens in Roon as well.
Under Device Settings for the Bridge (click on the gear icon next to the zone name) set the resync delay on the “General” tab. Try setting it to 1000ms and see if that makes a difference.
So I change this setting from 0ms to 1000ms - the same result. Tried also smaller value of 100ms - the same result.
For the moment the MSB Select DAC displays 3/44 and then goes to 16/44. This moment when it dispalys 3/44 is always present no metter what resync delay I choose. I think this is some kind of error in data stream.
Also I checked, that dCS has clock in sync, always.
Interesting, when the same track is played directly by dCS Bridge from UPNP/DLNA source the MSB DAC reports BIT PASS and the frequency is stable 16/44. Just verified this once more to be sure for 100%.
When I start the track it plays 16/44 about 3 seconds, than goes to 3/44 for a second or two and goes back to 16/44. When losing signal displaying 3/44 the noise is heard - then silence untill it goes back to 16/44.
I will try increasing delay beyond 2000 and let you know soon.
OK, I think that this is the issue. There’s a long and involved story here, but it all comes down to the way that the Roon code on the bridge has to generate its datastream to the DAC. In the case of the MSB the sync process takes a bit of time, but the bridge has to be rolling data in order for RAAT to work. In practical terms this means that the beginning of a song can be cut off when starting playback or changing sample rates. Technically this isn’t bit-perfect as the beginning of the track is chopped off, once everything is synced up then it is bit perfect.
The idea with the resync delay is to get Roon to roll out a period of digital silence so that the DAC and the bridge can sync up. That way you don’t lose the beginning of the song. Not sure if increasing this delay will cause the MSB test to pass as it may not like seeing the silence, but its worth a shot.
The reason that this works with UPnP and the dCS app is that they use a different method of holding playback until everything is synced up. Unfortunately this doesn’t work with RAAT in the current implementation.
Regardless, I’m confident that the Bridge is delivering bit-perfect data and the failure that you’re seeing is likely due to some limitations in the way that the MSB test works. The most important thing from a music standpoint is making sure that the delay is sufficient so that you don’t lose music at the beginning of a track. This is going to be most important when switching sample rates that are multipliers of 44.1K to those based on 48K (and vice-versa). Also, switching from 48K to DSD is one that can take some DACs some time to sync.
I do not think this is the issue you describe. I tried 2000ms and 10.000ms, and the length of time of 3/44 is exactly the same and exactly in the same place just 3- seconds after the track starts and then goes back to 16/44. The behaviour is identical and does not depend on delay set. This is my opinion proves the delay value has nothing to do with this issue.
Please note that I did not experience any dropouts or silence in normal tracks, this is different, this is a test track, the silence is recorded on this track. You can download the test tracks from MSB web site and see what is there, this is in support section, Please check it for yourself.
Also I opened dCS application where I can track the Unit Status in real time. During the track playback I have the LOCK STATUS in LOCKED state all the time, even I change from track to track with different base frequency.
So I think the issue is somewhere else, at least I think so.
I will be able also test tomorrow the dCS Vivaldi Upsampler and see what it displays and if it loses syns during playnback, maybe this would help.
The dCS network bridge incorporates a digital volume control in hardware. I’m not sure what its characteristics are, but it would definitely break a bitperfect test if it’s being allowed to touch the bits.
Indeed and I thought of that, but according to the screenshot above the volume level is at 0.0 and this setting does properly sync with the unit’s internal setting. Since there are no other volume control options in the Roon setup I’m assuming that the level is properly set at 0db.
I would be curious to hear the results of this test. Be sure that the Upsampler is set to output the same frequency and that it’s in “clone mode” so that it’s not applying any of its internal filters.
The purpose of clone mode is to completely bypass the internal upsampling functions and filters so for daily use it should be off (otherwise you’re getting no benefit from the investment in the upsampler). It’s purpose was for certain scenarios in which the input signal needs to be passed to the output without any processing at all (most of which have to do with maintenance and troubleshooting rather than listening)
I did the Bit Perfect tests by using MSB tracks with dCS Upsampler. No matter if the upsampler Clone Mode is in LOCK or ON position, the behaviour is exactly the same as in the dCS Network Bridge. Of course output frequency was corresponding to the input frequency.
