I’ve noticed, across multiple DACs, that the Resync Delay value is not always considered when playing back music.
When I start a new album (click/tap play album), it’s starting from scratch; I see the sample rate change, there is the selected delay and the music starts without skipping any of the audio.
However, whenever I click/tap the RW/FF button, in the same album and the same sample rate, Roon is releasing the DAC, re-locking on the DAC and then starting the previous/next track WITHOUT including the delay. This almost always results in loss of the initial notes in a song.
My Rega DAC will default to 44.1 kHz, but I can still see the lock light go off and then on, even just switch tracks in the same album. If there is a sample rate change, there is loss of initial music. Even if the album is all something other than 44.1 (e.g. 96 kHz).
My NAD D 1050 behaves the same, but that DAC requires almost 2 seconds to acquire a new lock or change sample rates, so the loss of initial audio if very noticeable.
Again, this ONLY when manually clicking on the RW/FF within an album or playlist. If I just let an album play through, no issues.
I think you have a bug in your code that is ignoring the Resync Delay when releasing/re-acquiring the DAC.
As a corollary, I have to ask: why are you releasing the DAC when RW/FF is clicked and the next song matched the current sample rate?
We break the stream on next/previous/seek operations because we don’t want those operations to incur buffering delays. By handling these operations in this way, we can use longer buffers, which makes playback more stable.
Note that I used the word stream and not lock, because at the level we’re operating that’s what we actually deal with–streams of PCM or DSD data at the boundary between Roon and CoreAudio, WASAPI, or ASIO. How your driver/DAC behaves with respect to lock when streams end and begin is up to the implementors of those parts of the system.
You are correct that we don’t apply the resynchronization delay when the configuration hasn’t changed, because we don’t expect any work to be done at the DAC under those circumstances.
We’ve tested with lots and lots of hardware–we have found that DACs connected via USB either switch rates instantaneously, or correctly push the delay back through the USB driver to make the application wait. Some DACs do need a delay when switching rates because they’re actually reconfiguring things inside, but we haven’t seen one (yet) that behaves like you’re describing.
Since our launch in May, we’ve run into several people who needed to use the resync delay feature (almost overwhelmingly to deal with problems during PCM->DSD transitions), but you’re the first person to describe issues with same->same PCM transitions.
This makes me wonder if you’re connecting your DACs via S/PDIF instead of USB, and perhaps if there’s something about your S/PDIF sender that’s making it difficult for the DACs to lock onto the signal promptly. Two seconds is a long time to grab an S/PDIF lock.
Going forward, some of these details are likely to change. RoonSpeakers/RAAT work is encouraging us to move towards a model where we break streams less often. I’m guessing that once that all makes it out there, you’ll no longer be in a bad situation.
In the case of the Rega DAC, it’s being fed via a Bel Canto S/PDIF converter. It’s pretty fast, but 0.5 seconds can be noticed on some tracks.
In the case of the NAD D 1050, it’s all USB, but via a Schiit Wyrd. The lengthy lock delay is due to the NAD’s design center around a very low headphone output impedance (I am just repeating what I’ve read - something about using a reed switch), but the switching delay is about 1.5 seconds, regardless of the interface used.
I would imagine that “reconfiguring things inside” occurs when switching between multiples of 44.1 and 48 kHz, as the oscillator in use changes.
FWIW, I don’t experience audio cropping with Audirvana+ and, consequently, I use shorter resync delay settings with that application.
As someone that likes to skip around within an album, this is a buzzkill, but it is what it is. Thanks for taking the time to explain.
I often think back to this conversation because we re-thought this behavior for 1.2, in part based on your feedback.
A few things have changed in 1.2:
Roon no longer immediately closes our relationship with the audio driver when you seek or skip
The resync delay is applied whenever we begin a new stream at the driver, not just when changing sample rates
We don’t release the device until you’ve been paused for 8 seconds (to release the device immediately, press Ctrl/Command-T or long-press on the pause button until the signal path light disappears)
I’m impressed that you followed up on this, after 5 months and am very eager to try this out.
I will say this about Roon’s Leadership Team: you folks are winning the hearts and minds of your customers in a manner I’m not sure I’ve ever seen from a tech company.