I haven’t looked at this again since yesterday (It’s on my list!), but a few comments…
Putting any kind of large buffer beyond RAAT is kind of begging for trouble–we’ve evolved our approach to clock management quite a lot in 1.2, and we are trusting that drivers that claim to ASIO present their timing behavior to us very honestly–both with respect to playing in real-time, and with respect to latency reporting. We were less dependent on this stuff being implemented properly in ASIO drivers in 1.1.
If you have a big (>500ms) buffer in JPLAY, it might help to increase the “Resync Delay” setting in Roon to a corresponding level. That way, Roon will fill JPLAY’s buffer with silence and stop making assumptions about clocking/timing during any faster-than-real-time buffering that JPLAY might be doing.
Another thing to consider–RAAT+Roon is a lot more JPLAY-like than Roon 1.1 used to be:
- Like JPLAY, RAAT runs in an isolated process from the main Roon app, so behavior of the main Roon server/UI is much less likely to influence the audio.
- Like JPLAY, RAAT has a large memory play buffer inside (similar to JPLAY’s PC buffer). Thinking through this from a technical perspective, this likely negates the influence of their PC buffer.
The ideal settings with 1.2 might be quite different from 1.1, and are probably more conservative (i.e. RAAT is doing some of these things now, so JPLAY can be set up to do less).
I don’t completely understand what the “DAC Link” setting means–according to their specs it has something to do with recovering the DAC clock, but that seems like a strange thing to attach to a setting measured in Hz–keep in mind that RAAT also drives its audio delivery based on the DAC clock, just like Roon 1.1 and Roon 1.0 did.