Fair enough. There are published resources that discuss USB 3.0 and Thunderbolt high frequency issues
It’s a high value product and the Explorer2 improves the feature set. I look forward to the Exporer2, Tidal, and Roon being apart of the most commonly found set-ups. (Certainly less than a MDMS C series!)
Thank you for your response and let us know what Roon plans on doing.
@brian
But surely your problem is EMF affecting the analogue signal through your headphone cable and has no bearing on the digital side of things ?
When you use other DACs I also assume you leave the main one where it is, and position the “alternative” DAC elsewhere, causing / necessitating a different cable routing - perhaps further away & less sensitive to the EMF…
Could be EMF through the headphone cable, or through the analog stage of the DAC. It’s not a digital domain problem.
Like to see memory play integrated into Roon.
This was already discussed here. Sounds like they said it would be an easy add once they switch over to 64 bit.
This is especially beneficial if one has a slow network devices, i.e. like portable wireless hard disk on the go. Memory playback is found in JRiver and can be enabled as an option.
See this comment that I just made in another thread…I’d be interested for your input on the points at the bottom. I’ve never heard memory play brought up in the context of stability before, so that’s interesting at least.
I’m tempted to say that if a storage device can’t deliver media at the required bit-rate, with our already-substantial memory buffering, that it not be quick enough to do the job.
We do take a more drastic approach with TIDAL buffering than we do with local/NAS content–primarily because when TIDAL was new and growing rapidly, their CDN was in awful shape–TIDAL does its more substantial buffering to disk, not memory, because memory buffering is significantly more likely to adversely affect performance/stability.
Hi Brian,
In both case JRiver and Roon will playback immediately once I hit the play. JRiver is configured ‘Play files from memory instead of disk(non-zone specific’). The PC is connected via Ethernet and the source is NAS, test file is DSD128, 9 minutes duration. Take a look at the Ethernet performance in Windows Task Manager. In JRiver configured with memory playback, part of the file is copied to the PC in few seconds but the bit-rate jumped to about 700kbps and down to 0kbps. In Roon bit-rate peak around 24kbps to 35kbps across the 9 minutes duration of the track.I think playing back from memory is more fault tolerance against caching problem.
Jplay also exhibits this same “spike” behavior as well.
As an aside, it’s really more about latency than throughput; especially when you are looking at gapless playback issues.
I just moved my library from a WD MyCloud 3TB onto a Firewire 800 direct-attached disc on my 2011 Mac Mini and my occasional gapless playback issues disappeared.
Funny thing is: both my NAS share and the DAS HDD have very similar numbers with Blackmagic Speed Test. But NAS always suffers from greater latency in the initial read request - there’s more protocol overhead and the target has to react to the request, from an operating system standpoint. This is the case even with higher-end NAS devices, in my experience.
I never have these problems with MPD playback, using a mounted NAS share, and it’s my belief that MPD is more aggressive in pre-loading the next track to make gapless playback completely smooth.
So, it’s not that Roon needs more buffering, it’s that it needs to request it earlier in the playback process.
We begin loading/buffering the “next track” as soon as it becomes the “next track”. At that point in time, we handle the header parsing + pull out 10s of audio into RAM–in order to prevent the exact kind of issues you’re describing.
I don’t doubt that you’re seeing problem. It would really help if we could figure out how to reproduce issues like this in-house, so we can instrument the system while the problem is happening instead of guessing at the causes.
One way is to use a network traffic shaper to introduce increased latency between a storage appliance (NAS) and RoonServer, as well as the Roon endpoint. netem is a good one for Linux, Traffic Shaper XP for Windows and Network Link Conditioner for Mac OS (optional Xcode package).
You need to dial-up a high latency condition between a NAS device and RoonServer running on something normal that isn’t high-powered, but allow reasonable throughput between the endpoint and the RoonServer.
If it helps, here is my config: Mac Mini (mid 2011) w/ 8 GB RAM and SSD for OS and Roon; Apple Airport Extreme WAP/switch w/ GigE between the Mac Mini and a WD MyCloud 3TB with an iTunes library on a root share (Apple Lossless Files) that is watched (i.e. I am not sync’ing as an iTunes Library). Then, Airport Express (very closely positioned to the Apple Extreme) and then wired connection to a Bryston BDP-1 in Roon Ready mode.
Finally, use tracks that really accentuate even the smallest delays in track-transition. I personally use Steve Roach’s “The Magnificent Void” for this, but many classical albums will work.
Let me know if you need more from me or I can help in any way.
Would it be possible to buffer more than 10s of audio through more ‘brutal’ copy, i.e. higher bitrate and music is playback for example about 40s to 60s before another high bitrate copy for a very large file? For small file like FLAC, it should fit into RAM entirely so one big copy is all it needs. Add this as an option which users can enable and disable.
@Krutsch, OK. I will try that here.
@MusicEar, anything is possible, but it’s not clear whether your proposal is the right thing to do yet. My general concerns about “memory play” features from the other thread are still open, and your proposal is one of many possible ways we might address the issue. Any ideas how we might reproduce what you’re experiencing here so we can understand it better in person?
Hi,
Now I tried on slow wireless connection on the Surface Pro 4, the device is a 2TB portable Seagate Wireless plus which acts as access point and can concurrently connect to internet. I posted some Wireless performance both on JRiver and Roon. For DSD128, 9 minutes tracks, JRiver pre-buffering took about 4 secs before music started to play… Now there’s a delay, but if I let it play to the next track, the music does not have a delay because when the first track was about to finish, pre-buffering occurred. For small file, a 16/44.1 WAV, JRiver can copy this file in matter of secs and there’s no delay to music. Once the copying is finished, the wireless goes down to 0kbps. In case of Roon, both large and small files behave almost the same.
Now, when I playback in Roon, especially large file like DSD128 and 24/192 on a slow network like this, occasionally, I got ‘breaks’ and what Roon does it will automatically advance to the next track. In JRiver, I don’t get break. I’m not sure if Roon buffering is to the low side but getting more file copied(brutal copy to the highest bitrate available to the network) to the PC is likely to ensure music don’t get ‘break’. There are some advantage in portable application, in this case for small files, the entire file can be copied to the PC while allow the portable hard disk can spin down and conserve battery.
[quote=“MusicEar, post:10, topic:12412”]
while allow the portable hard disk can spin down and conserve battery.
[/quote]that’s a sure way to shorten a mechanical drive’s lifespan.
I just had a look at what is going on in my configuration and got the following results:
1 client
2 clients
3 clients
Setup is a HP Microserver Gen 8, i5 3470T, 8 GB RAM, 240 GB System SSD plus conventional drives for storage that is connected to an AVM 7490 router through a gigabyte ethernet line.
Clients are several Marantz consolettes all over the place plus local PCs and a raspberry pi 3 running roon bridge feeding a Lyngdorf TDAi 2200 via S/PDIF.
Above screenshots were taken streaming aac-Files to one consolette, my pc and the pi via WLAN.
I believe it is essential to have roon server and storage in one local unit. A NAS solution means that the server has to request the file and to send it, which leads to higher network load (which may be well more than twice as high due to collisions appearing when the network is congested).
Hi guys, was the play from RAM feature implemented in this 1.3 version?
Basically the songs being read from RAM instead that from disk…
I still don’t have a Roon license, that’s why i asked.
Thanks
Play from RAM was never advertised as a feature for 1.3. So, no. It might be in the future.
I would love that! I find I have the occasional dropout with Roon and not with JRiver using that feature.
