I have a transport (Cambridge CXC) connected to the SPDIF2 input. Often, when starting playback of a CD, it will show a “Non Audio” message on the display (and no sound). Restarting the Rossini fixes the problem, but eventually it gets into this funk again.
Miguel Barrio
What you see seems correct. The DAC will display " Non Audio" whilst it is not receiving any audio from a transport and is therefore not receiving any information via the S/Pdif interface about bit rate or sample rate to display. Once the disc starts to play the DAC should display both ( and give sound). Is it not i.e. you can’t play discs? Once the first disc has been played the setting will be remembered and should remain until there is a change. This should not happen playing a sequence of CDs as they are obviously all 16/44.1.
I assume from your reference to " a transport" that it is not a dCS model as that may add complications. I have one transport that is incompatible with any dCS DAC though for a very good reason. It was made before the S/Pdif protocol was adopted!
That is not what I observe. When the transport is not playing, I see the standard idle screen. When I start playing a CD, I see the Non Audio message. The Non Audio message never shows up when there’s no signal coming in.
The transport is a Cambridge CXC (I also edited the initial question to include this info).
Miguel, I can only suggest that there is some sort of incompatibility between the CXC and the Rossini. What you are saying seems to indicate that Rossini is not recognising the S/Pdif stream ( I should point out that dCS were a player in defining the AES protocol of which S/Pdif is a part so there is not likely to be a non-standard implementation on their part).
Have you any other transport ( e.g an old CD/DVD player with coax output) just so that you can see if it behaves as expected? And. of course, try another interconnect.
So what is the clock mode you have set for the relevant S/PDIF interface? I think you get this in any other mode than “Audio” for a source that is not clocked by the Rossini’s own clock (which may or may not be slaved to an external clock).
Clock mode is Audio - ie it recovers the clock from the SPDIF signal.
I do have other transports. When I bump into this issue again I will try another transport to see if it is a state in the Rossini vs the CXC.
I wouldn’t be surprised if the Cambridge Audio’s proprietary S3 Servo board is doing something funky before it puts out a proper S/PDIF signal… but I’m just guessing 
I have now read the CXC User Manual. It is pretty brief as the transport offers only basic features. However I did note that there is a set up mode which displays a menu of options. The guide does not reveal exactly what those options are but it may be worth checking this aspect to see if anything has been selected that could result in your issue.
One other thing occurs to me. What you describe could occur if you are trying to play non-standard CDs e.g. a CD-R of , say, MP3 or other rips.
Incidentally the manual is specific that the TOSLINK cable should be intended for audio use. I don’t quite know what they mean by this but there it is.
The synch issue would be unlikely to produce this problem. Selecting the incorrect one should not produce a Non Audio message. It should play but you may encounter synchronisation issues such as glitches or just poorer than ideal sound. In any case that selected seems to be correct.
This message on the Rossini indicates that is receiving a valid SPDIF stream, but the stream contains messaging saying “this is not a PCM audio stream”. The transport is the most likely cause of this. I haven’t ever seen options relating to this on a transport, but it is entirely possible something odd is happening between CDs and CD-Rs.
When the issue next occurs, switching the transport out for another is definitely a valid test.
I tried the following:
1- Play CD from Cambridge CXC to SPDIF2, getting “Non Audio” on the Rossini. As it starts playing you hear the relay clicks but eventually decides it’s Non Audio (which it is not)
2- Connected an Oppo BDP-93 to SPDIF2 (same cable moved from CXC to Oppo). Played the CD, same issue, I get “Non Audio” while playing.
3- Powering the Rossini off then back on makes it work again and plays music (with both units).
Congrats, problem seems solved.
dCS devices are actually “audio computers” , and like regular computers, they need a reboot when you change peripherals.
Not all the time. This happens ALL THE TIME while other methods of playback (eg RoonReady) work just fine.
Well I think that you have eliminated the the player as a suspect. That leaves three possibilities:
The S/Pdif 2 input is faulty. But you say that Roon ( if I assume that you mean via the same input) works then that is also eliminated. If not…
The connecting Toslink cable ( unless that is also used for Roon).
The medium that you are trying to play is of a type that cannot be processed via this input.
What are we left with?
I use Roon over RoonReady (ie over the network) so this is altogether different. I also use the optical input for a ChromecastAudio dongle. And this happens with all CDs, not just one. So 2 & 3 are out.
It is possible the SPDIF2 input is the issue, but again this is odd as a reboot of the Rossini clears it up - so it is not a hardware issue with the input.
Hence I am asking dCS for help.
Has to be a problem with your Rossini or your sources - just checked this with my Rossini and an Accuphase (SA)CD player. No issues whatsoever. So not a generic Rossini problem.
Well of course it’s one of those. Once you reboot the Rossini, it seems to get in a good state. It plays, I can switch sources and that plays too, I can play PCM, DSD from Roon then go back to SPDIF2 and it works. But eventually in a few days it will get into a bad state, and I think it might be the Rossini.
This turns out to be a bug in the control software of the Rossini. When you have SPDIF3 plugged in (the optical input), then SPDIF2 can behave this way. Unplugging SPDIF3 clears the problem.
dCS support told me there will be a software update to fix this bug.