David, that particular buffer (on the DAC) is associated with the synchronous inputs, and has nothing to do with FLAC decoding.
FLAC decoding happens on the Streaming board, which, if I’m not mistaken, has 2Gb (256MB) of RAM, which should be more than adequate.
The logs of my Bartók and Rossini mention:
nand: Toshiba NAND 512MiB* 3,3V 8-bit
nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 128
Thanks Erno, I stand corrected… I think 
(when you look at the available User-space memory managed by Linux kernel on the Streaming board, it seems to be just under 256MB).
That is correct:
Memory: 241220K/261120K available (6303K kernel code, 404K rwdata, 2020K rodata, 232K init, 8269K bss, 19900K reserved, 0K cma-reserved, 0K highmem
After this status, the rest of the software is loaded on the physical 500MB memory. It seems to have 12 partitions. How they are getting filled by the FLAC decoding process I, of course, do not know.
Whether you don’t look at it, 24 / flac 192 audio material, is reproducet with non gaples the fact remains that the DCS devices process it with errors. The proposed solutions are effective, but require certain knowledge and efficiency in using the conversion software and its purchase. Since the problem is playing streaming content in 24/192 flac resolution, it means that the problem lies in the way such material is processed by DCS devices. Service providers streaming the flac 24/192 format and putting large image files inside the uploaded files probably have the right arguments to do this. The technical description also shows that there is so much memory in DCS devices that the flac / 24/192 processing should not be a problem. I do not have any material played gaples in the resolution of 24/384 flac and yet the manual says that DCS supports files with this resolution, but it has not been added that after appropriate preparation … It is always the case that correcting one error can generate another. I am ready to try out the beta software which will include a fix for this bug.
Apologies for the delay in coming back on this one folks. Could someone provide an example of an album which is experiencing gaps between tracks on Qobuz? Despite best efforts, all the 192k albums I try seem to have hard finishes to tracks so no overlap to hear gaps in.
James the album that started the thread is a fair choice : Bill Evans Trio " On a Friday Evening". Although the track indicators are at the conclusion of each number if you listen to the album in a resolution lower than 24/192 you will hear that the audience noise continues ( quietly) through to the following number (i.e. played gaplessly). I would do this first to establish what should be heard. Using 24/192 instead you will hear a break in the audience noise as a brief gap is inserted ( can sound as if a click or tick is added as well).
James, its very obvious on John Coltrane, “A Love Supreme: Live in Seattle (Live)”; 24/192k
Then there’s the promised fix for dropping the start of .DSF files that I’ve been waiting for for 17 months now…
It uses a buffer to facilitate this but that buffer appears to be a fixed size. The manual says it is .72 seconds for 44.1k files down to .16 seconds for 192k files. With a high sample rate Flac file with an abnormally large metadata block it probably simply runs out of time to process the metadata before the buffer empties leaving silence until the flow of data resumes.
I suspect this is the same issue with fixing the Rossini issue with dropping the first .84 second of a .DSF track when it switches from PCM to DSD; I suspect it drops the data because it doesn’t have buffer space to store the data while it’s examining the data to ascertain whether it is PCM or DSD, something every other PCM/DSD DAC does as a matter of course.
I don’t think dCS ever thought there would be a need to buffer up to a second of DSD 128 data before sending it on through the DSD decoding mechanism, and all the Rossini can do is drop it on the floor once it realizes the datastream isn’t PCM.
Lack of buffer space would apply to both these situations, even though the buffer would only need to be a few MB in size.
The buffer you can toggle seems like an obvious candidate, but it may not be large enough.
Reading about the problem with switching from PCM files to DSD, I thought to myself if this problem is not related and has the same reason. It worried me, however, that in such an important product as the Rossini it had not been fixed for over a year.
dCS updates have always been slow in coming, and I’ve been willing to cut them slack due to COVID, but I suspect that promised Rossini update will not ever actually come.
Perhaps it’s paranoia, but it’s inevitable Rossini will be replaced and dCS never updates discontinued products.
Also, to clarify my earlier comment about buffering, what the Rossini would need to do is buffer data as it comes in while it determines whether the stream is PCM or DoP and if it is DoP it would need to start DSD playback with the first bit received and forever lag behind what was just received.
Instead, when it realizes it’s DoP it decodes bits from that point as DSD and the data received earlier is just lost.
I currently have a similar problem with files with a resolution of 24 / 352.8 (DXD). The beginnings of the recording are cut off, maybe 1s. It was harder to catch because it’s a studio recording. Of course my Bartók has all the latest updates. It seems that the DCS devices have some problem with the dense files because between DSD128 recordings I hear a slight click in the speakers.
Best Regards Robert
Hi Robert,
What is the source for these audio files? UPnP? USB?
Thanks
Phil
The problem concerns Flac 24 / 342.8 and DSD128 files stored locally and played from my Qnap server with Minim Server (latest version) installed. Lan connection, DCS Mosaic used to control file playback.
This is to report that the problem persists on 24/192 files.
It is impossible to hear an opera if Mosaic doesn’t play gapless.
Removing embedded artwork doesn’t work.
I use minimserver 2.2, but streaming from Qobuz you get the same issue.
Same albums play perfect in a Linn system.
Vivaldi One sounds sublime, but no way to listen to an opera, oratorio, … 24/192, if Mosaic fails playing gapless on 24/192.
I can’t understand that after all this time dCS doesn’t even try to solve the problem.
Hi Manel,
Thank you for raising this again - I have been discussing this issue earlier this week with our software team and I am assured that it will be addressed.
I have been given a release expectation - which is really good - however I’m always wary of making commitments early on so I’m not going to just yet until I have the test code running on my mule at home but I am assured it is prioritised…
BR
Phil
Thanks a lot for putting the resources to fix it.
In classical music (mostly vocal) that is very important and ruins the listening experience.