Yeah, I could afford it, but in reality, if that is what DCS proposes as a solution, then they owe me $14.99 a month or whatever a Roon subscription costs.
Or at least buy me a copy of JRiver, where I can also add a gap between tracks.
I don’t think anyone has dismissed this as a nit.
But they do have a buffer, and that’s easily demonstrated. Why that hasn’t been employed for a solution is the question I find interesting.
I can’t deny I was disappointed when I realised Mosaic 1.1.3 didn’t resolve this issue on the Vivaldi, but I wasn’t surprised because the resolution would have involved an update to not just the network board on the Upsampler, there needs to be an update to the DAC firmware as well, which wasn’t part of the Mosaic 1.1.3 update obviously.
However, for one-box units like the Bartok, 1.1.3 does solve the issue. I’m not sure why that isn’t the case for the Rossini. 
Gapless albums are not a problem on either platform, as long as you let the album play by itself (as it’s supposed to for a gapless album). When playing a gapless DSD album for example, neither platform switches to PCM format in-between tracks, it stays on DSD right the way through. I’m not sure why you’re having problems with gapless on the Rossini.
That said, If you manually intervene in a playing gapless album, to forward to the next or previous track for example, then the problem does manifests on the Vivaldi stack (though not on the Bartok).
In the case of the Vivaldi stack, there are two buffers involved; the buffer on the streamboard within the Upsampler, which we can’t control, and the buffer on the DAC, which we can turn on or off.
2 Likes
They have a buffer, but it depends on how it’s implemented.
If the buffer that you can toggle on and off is placed such that it can only be used for PCM data, then it wouldn’t be usable for cacheing DSD data.
It also might not be big enough to store the almost one second of data it needs to when witching to DSD mode.
Understood. However, pulling the cable seems to demonstrate a buffer in DSD as well. It may be shorter than the PCM buffer, I haven’t put a timer on either. As you said, it’s possible that its implementation is difficult to access for this purpose.
1 Like
I’m sure our dCS friends are actively working on a Control board firmware update to address this issue. Not sure there’s much to be gained by trying to guess how the buffers are implemented 
2 Likes
No doubt! 
I’m sure they are, but will they come up with a solution before the EOL their current products? That’s what I am concerned about.
I know it’s no use to guess about buffer implementation, but I was discussing what may be the technical issues involved.
1 Like
Actually, Greg’s idea was pretty good; just unplug your UPnP Server from the network while streaming a DSD track - my Vivaldi stack continues to play for a good almost 4 seconds. I seriously doubt buffer size is an issue 
1 Like
Exactly Bill. That kind of fix for existing problems is of a different nature to continuing to issue upgrades with new features. Will they service this issue after current production of Vivaldi ends if they haven’t the resources to deal with it before? This type of issue will give me pause to think when I come to consider purchase of its successor.
1 Like
If I setup JRiver to feed audio files over a network using a DLNA server, it plays back each file, gapless or not, as a separate file it sends to the RP. There is no way for it to send a hardware sync delay via DLNA because it sends the audio files as the actual unaltered files themselves.
The problem is that when the RP hits the end of a file being received via the Network, it will reset itself to PCM mode, meaning the first .84 seconds of the next DSD file get skipped/dropped every time. You can even watch the display do it between files it is sent, as it goes from DSD -> PCM Bitrate -> DSD.
There is no way around this that I have found.
The only way to get this to work in continued playback between tracks is to feed the tracks using JRiver or another mechanism over USB; when using USB if you don’t jump tracks, the mode will stay at whatever it was last and JRiver also allows the option of inserting hardware synchronization delays between tracks via USB.
This functionally makes the RP useless for playing DSD tracks over via DLNA that do not individually start with at least .84 seconds of silence.
In summary, what you state about continued playback of DSD albums is true only over USB; there is no way to get at least the RP to operate properly over the Network.
Bill, I don’t have any experience with JRiver, but looking at this post of yours, it’s seems quite clear that thats where the bulk of your problems might be!! 
I’ve got multiple UPnP Servers at home - Asset, MinimServer, and Twonky - none of them have any problems streaming a gapless DSD album over Ethernet without any such “reset” to PCM in between tracks on both my Vivaldi stack and Bartok. I’m sure the Rossini is no different.
1 Like
I f you are right then there may be a solution in the JRiver settings menu. I used JRiver for a few years in my early days of computer audio. When playing DSD albums it is necessary to select the “Bitstreaming " option - which I assume that Bill has done or he wouldn’t get any music. The next option is selecting prebuffering . My old v.23 of JR has 6 seconds set which I see JRiver marks as " recommended”. The next option may fit his problem precisely. You need to select " Use gapless for sequential album tracks".
I have never experienced problems with gapless replay using JRiver with the selections above checked with either Paganini or Vivaldi.
I would remark that the inbuilt DNLA feature of JRiver did not enjoy a stainless reputation during my period with JR and, although I didn’t use it myself, I recall quite a bit of traffic relating to it on the user forum. However things may have changed given the number of iterations since v.23.
Of course there is no problem with gapless using Mosaic.
1 Like
I tried JRiver quite a few years ago. As I recall it was very flexible, but a bit of a nightmare to get working properly because it was so flexible (I might still have a license actually, maybe I’ll give it a go ).
1 Like
Yes, it has a bit of a steep learning curve even if you are only using its audio replay facilities.
As an update, Anupc thought it might be the JRiver DLNA server, and that looks to be the case.
If I play a DSD album using Minim 2.0.18, it works as described - the first track is cut off, and any attempt to seek back or forward will cut off the beginning of the track, but tracks will flow from the current track properly if allowed to progress naturally.
Full disclosure: I despise JRiver and always have even when I was a paying user (maybe more so because of it 
). However, I don’t understand what sending “unaltered” files has to do with being unable to send a sync delay.
The basic theory is this:
If the server sends each song as a complete unaltered file, there’s no way to insert silence without altering the contents of the file.
Arguably it already has to, though, to be able to send the .dsf data via DoP.
Yeah, that basic theory doesn’t make sense to me. Silence between files or in files doesn’t require any diminution in bit-perfect quality. And that’s the only alteration I care about. Roon’s sync delay changes neither a track’s duration nor its bit perfect quality.
Being in the computer industry I look at this this way, and I may be way off when it comes to DLNA.
Assuming you have two song files:
A: [ Start ] Data [ EOF ]
B: [ Start ] Data [ EOF ]
I can see where the server can wrap those in DoP headers, e.g.:
[ DoP Start ] [ Start ] Data [ EOF ] [ DoP End ]
But it becomes trickier if it has to deliver:
[ DoP Start ] [ Start ] [ Inserted Silence ] Data [ EOF ] [ DoP End ]
Another issue is JRiver may not handle the next track info properly as Minim manages to be able to play the next track without closing the connection (causing the RP to reset to PCM mode), but JRiver apparently closes it at the end of each track sent (perfectly reasonable for a file server.)
I’m just grasping at straws here.