Playing DSD .dsf files from the beginning on the Rossini skips the first 0.84 second of audio

Support
15

Yes, except:

  • When playing a sequence of DSD files (an album or playlist), every track but the first plays from the beginning.
  • If the .5s delay is inserted before the track data is sent, the track plays from the beginning.

Based on what I’ve seen from surround processors, what I suspect is the Rossini examines the new data stream to determine whether it is PCM or DSD, but by the time it does so it takes 0.84s before the DSD decoder is enabled. However, looking at the spec, the number of frames required to make this determination should only introduce a latency of around 180 µsec (DoP open Standard), but the Rossini needs a delay of about 500,000 µsec to reliably play the beginning of a new DSD track (I tried a .25 second delay but it wasn’t long enough.)

For example, to avoid audible glitches, many surround processors will take a second or two after seeing the start of a bitstream before they start emitting sound, as if it assumes it is PCM it will instead emit a burst of white noise before changing to Dolby mode - but this also means if you send it PCM data you may lose the start of a track as is happening here. You can shut this delay off on many processors to avoid this effect, at the risk of hearing a momentary noise burst when sending it Dolby Digital data.

The question is the implementation - once again my Oppo UDP-205 can do this determination on the fly, but perhaps there’s something unique to the Ring DAC that they can’t just buffer the data and play the DSD bitstream back from the buffer if it determines it is DoP, where conventional hardware DACs like the Oppo’s ESS9038PRO can.

I sent a support query via the dCS “Contact Us” link on their web site, but I was hoping they’d chime in here.

16

I suspect that only dCS technical staff can knowledgeably answer questions about the architecture of the processing in Rossini. However I doubt that the answer is related to this unless there is a configuration setting error as if it was to do with fundamental processing then it is likely that all of us with Gen 3 dCS DACs would suffer from it which it seems we do not.

Your further clarification of your problem has shown that I originally misunderstood it. There is no PCM/DSD switching and it occurs with .dsf files irrespective of the data “transport” used unless there is an opportunity to insert some kind of buffering or latency.

It is currently looking as if help that we may be able to provide here on the forum has been exhausted unless Andrew or James takes it up . This does now seem to be something for which dCS technical expertise is needed. It may be a hardware fault ( rare but they occur) which would not be possible to resolve online in any case and would almost certainly require liaison with your local distributor. Remember that your computer keyboard is not the only resource that you have for contacting them. Pick up the phone starting with your dealer. I do not know where you are but there is a list of international distributors also available on the main dCS website. dCS itself in the UK does have a customer service desk ( remember any time zone difference) but your local dCS contacts should be tried first as it is their responsibilty to sort the issue out.

When you find out what is that cause of the issue please post brief details here so that we can all learn.

Good luck

Pete

17

Thanks.

As I said, I don’t beieve it’s a hardware issue as I’ve since heard from other Rossini owners experiencing the exact same thing when playing DSD .dsf files, and I suspect it is a bug involving decoding of DoP, whether over the network or via USB.

I suspect it may also be true via the digital inputs except for dual AES/EBU from an appropriate transport.

If I don’t hear from anyone here, I will post back if there is ever a resolution offline.

18

Bill, you’ve got a Rossini clock yes? Whats the clock Sync Mode setting on your Rossini player (when the problem manifests)?

19

It looks like the clock is W1, but I verified the behavior is the same even if I power off the clock so the clock mode becomes “M.”

20

I was contacted by James at dCS, and he asked what the display showed when this ocurs, and it appears to implicate the DoP detection mechanism and/or the switch between PCM and DSD modes.

I sent him this:

The easiest way to see this is to use software like JRiver to play the file over USB and that has a setting for how much silence to insert before sending music data (Tools > Options > Audio > Settings > Play silence at startup for hardware sync > (amount))

When stopped, the display reads 0/176.4.
When it detects the DSD data, it switches to read DSD.

If there is no delay, the music does not start until the display switches to DSD.
If there is silence inserted, it switches to DSD, then playback may start properly.

These operations all involve pressing “stop” and then “play”:

If I select no silence, music starts at what is approximately 0.84 second into the track (determined by looking at the track in a music editor.)
If I select 1/4 second silence, music starts about 0.25 second into the track.
If I select 1/2 second silence, music starts as it should at the start of the track.

What is notable is if I jump back to the beginning of the track via USB, it will continue to play the beginning of the track properly once it “knows” it is DSD (which is why you have to hit “stop” to get it to read 0/176.4.)

Via Network, the display changes to 24/176.4 and then to DSD even if I jump back to the start of the track, so there is no way to play the track from the beginning as, once again, the delay seems to be in detecting it is DoP DSD rather than PCM.

The issue seems to be that once the unit knows a datastream is DSD, it doesn’t send the data frames it has received to that point to the DSD decoder, it apparently just discards them and interprets all FUTURE received data as DSD until the end of the track.

Changing the buffer setting does NOT affect the loss of the first part of the DSD track, it is lost whether the buffer is on or off.

The behavior I mentioned above with the unit defaulting back to PCM is clear between inputs:

  • The USB input keeps the data type as DSD, so you only lose the start of the first track you play in an album or playlist as long as you let the songs play through and don’t jump to a new track. Jumping to a different track causes the player to do DoP detection again and again the start of the song is cut off.
  • The Network/DLNA input resets to PCM with the end of each track, so you lose the beginning of each successive track.

So as I mentioned, say you have two DSD tracks that play as an album:

Via USB:

Played continuously starting at Track 1:
Track 1: First part cut off
Track 2: Plays normally

Jump to Track 2:
First part cut off

Jump back to the start of Track 2:
Plays normally

Via Network:

Played continuously starting at Track 1:
Track 1: First part cut off
Track 2: First part cut off

Jump to Track 2:
First part cut off

Jump back to the start of Track 2:
First part cut off

This behavior means it is impossible to properly play a DSD album via the Network, and the only way to properly play a DSD album via the USB input is to start playback and jump back to the start of the first track - neither is a really good option.

21

Or, to summarize:

The problem seems to be that when the Rossini gets a PCM datastream it needs to decide whether it is DoP and if so, change from PCM to DSD mode.

As I mentioned before, the unit should be able to do this within 180 µsec according to the DoP standard, but for whatever reason it takes around 1/2 second for the Rossini to detect a DoP datastream and change to DSD mode.

That in itself wouldn’t be an issue, but the Rossini further seems to discard all data received before it switches to DSD mode rather than buffer the data and decode it as DSD, thus the need for the ½ second of silence preceding the track (presumably the silence is encoded as DSD DoP) to get playback to work properly.

However, there is a second issue related to the switching:

  • When receiving data via USB, the Rossini assumes future data until a jump to a different track will be of the same form, so once it clicks into DSD mode it assumes all succeeding tracks are DSD, and if you jump back to the start of the same track it will stay in DSD mode and play back properly.

  • When receiving data via the Network, any track change resets the Rossini DAC to PCM mode and causes it to have to switch all over again, meaning there is literally no way it can ever play a DSD album properly via the Network, it will always cut off the beginning of each and every DSD track sent as DoP regardless of whether you have jumped to a new track or are playing a sequence of them.

I don’t have an SACD transport, so I don’t know if SACD sent via dual AES/EBU somehow avoids this format switch delay or if the same cut off of the beginning of the first (or successive) tracks occurs there.

So the question is, now that I have this nailed down, can dCS fix it or is it due to architectural quirks of the Rossini as opposed to the Vivaldi (or Bartok)?

22

Is there anyone else who plays .dsf files on a Rossini who could confirm?

Can anyone with a Vivaldi confirm that following the precise procedure I noted above does not result in the same behavior on your hardware?

23

I play them a lot - but through Roon. I have not observed the 0.84 delay that you see.

24

Same here on Vivaldi. And I specify a buffer in Roon to make sure I don’t experience this problem. To my recollection, I’ve never experienced it with the Upsampler. The reason I have Roon set that way is for the MSB. It did, on occasion exhibit this behavior, but only sporadically, never consistently.

25

Hi all,

We have confirmed this issue and identified the source; the fix will be implemented as part of the next Rossini software release.

2 Likes
26

I am the new owner of a Vivaldi DAC and Upsampler (with a Rossini clock), and have this issue. The first part of MQA songs is clipped. This happens after an audible click from the DAC as is changes sampling rate I guess. Will there be an upcoming fix to this similar to the promised fix for the Rossini problems noted above?

I am just entering the world of streaming audio, and I love the DAC and Upsampler. For now, I’m not too convinced I hear much difference between MQA and CD quality, but I’m burning in some new speakers so time will tell.

27

Your problem actually seems fundamentally different to the DSD via DoP timing issue that arose with Rossini. The implementation of MQA is very different to DoP not the least being that two different components are involved in a Vivaldi setup. For MQA the upsampler carries out the MQA decoding with the DAC performing the rendering task.

I am, however, a little surprised as I think you are the first that I am aware of to raise this specific issue so I am guessing that something may be amiss.

My initial thought is to wonder if are you actually rendering MQA? if not that may explain your difficulty in telling it apart from CD quality. So is your DAC software v. 2.11 or above and your upsampler software v.2.10 ? If not then we may have a simple answer if it is then I suspect that input from dCS ( Andrew or James) may be needed.

As a mischievous answer I would suggest switching your subscription from Tidal to Qobuz. An immediate solution giving full hi-res flacs with gapless replay ( not available with an MQA/dCS combination) and without any MQA malarkey :grinning:

1 Like
28

Dare I ask if there is any time frame for when that next Rossini software release might be coming?

Thanks in advance!

29

Before I left Tidal, I can confirm that I did not experience this problem. Are you using Roon?

2 Likes
30

David, since the Rossini Clock only has a single set of clock outputs, how are you properly clocking both the Vivaldi Upsampler and the DAC? Check your Sync modes on them are properly configured, along with the DAC’s Buffer, should be On.

2 Likes
31

Damn, that’s embarrassing. Thanks @Anupc for possibly catching the obvious.

32

:wink:

David might have the Rosinni Clock’s outputs 1 & 2 (the 44.1k & 48k clocks) connected to the DAC, while the remaining 3rd output (fixed @ 44.1k) to the Upsampler. That should allow him to properly synchronise when streaming from Tidal MQA tracks with a rebook base rate. But I’m not sure what happens when the Upsampler unfolds the MQA track to 96k; does the lack of an incoming 48k clock on the Upsampler impact the AES bit stream? :thinking:

Or more likely, the other alternative would be to dual clock the Upsampler with the Rosinni clock, and have the DAC set to “Audio” clock, which is bound to have problems when the music starts as it takes the DAC sometime to synchronise to the incoming bitstream. [Edit] I just remembered that the Upsampler does have a word clock output that could be connected to the DAC, with rates depending on the AES connection to between the Upsampler and DAC.

All in all, [still] a less than ideal configuration thats likely to produce challenges.

1 Like
33

Anupc, that is correct. No worries though lots of rich content available otherwise…

Slainte,

Mitch

34

This is an old thread, but most closely describes an issue I’m having. I have a library of SACD discs that were ripped to DSD and copied to my NAS. The first .5 seconds (my guess) are truncated when played thru my Vivaldi stack (Clock, Upsampler and DAC).

If one of these songs is selected, I can hear some noise from the stack as it changes frequencies, and it appears to be searching to match the frequency of the song.

If I select an entire DSD album from my NAS, this only happens on the first song, the rest playback perfectly. I guess once the frequencies are lined up it works fine.

If I build a playlist of DSD files, it always happens on the first song, and then sometimes on the following playlist selections.

This also happens on some, but not all, high-res songs from Quboz.

I found a DAC Buffer setting in Mosaic, and thought this would be the solution, but it is not.

I’ve poured over the user manuals thinking I might not have it all setup correctly but I’m stumped.

Any advice would be greatly appreciated.

Thanks,

Mitch