Dear Roon team,
I use HQplayer and my preferred interpolation function is the sinc-M function, similar to Chord. It has a sin x / x sampled over 1 million samples, that represents 1.3 s at 384 kHz. But this on-the fly interpolation needs some time to compute on the fly, especially when followed by a convolution filter of the same size, in overlap-add mode for more accuracy. So this means I wait between 14 and 15 s before a piece of music starts, on a quad-I7 Mac Book Pro at 2.6 GHz.
The request is that this delay should be taken into account while playing:
in the moving cursor over the dynamic time series window
in the text sliding on the Karaoke-type window.
If assessing this delay automatically is difficult, a simple entry to define it manually would do.
That would be a simple modification, a useful one in that form. I am not the only one using that accurate interpolator in HQplayer, and the problem can arise in other configurations.
Thanks for your comments and from other user’s feedback on this issue and proposed fix.
How can Roon anticipate what an external program is going to do? Especially as the delay can vary significantly between settings? At the moment Roon hands off to HQPlayer and is completely oblivious to what it then does with the signal.
Thanks for raising that point that we users cannot know. If you cannot get that timing info back from HQplayer - or other interfaces, the simple thing to do is to add in the HQplayer window of Roon an optional entry for a manual delay in seconds, défaut 0.00 s. I would happily enter 14.5 s in that field and be fine for synchronisation within about half a second. Better for the sliding red bar on the dynamic display and much better to sync rolling text of Karaoke mode with music.
The additional code needed to implement that at these three places is as short and trivial as can be, and is not incompatible with a better future method to compute that delay.
In the future when you stream video (who knows) you will have to manage also a video delay anyway…
On my system it is very consistent. The Mac Book Pro I use is fully dedicated to Roon and HQplayer. Those are the two programs that are not put into inactivity (a feature of Mac OS Catalina), so that the computing power is uninterrupted and dedicated to music processing.
In those conditions the delay is very stable. I think +/- 0.5s is a fair estimate of stability.
So yes, an easy add-on with benefits.
I forgot another detail about the compute delay. When playing a list of pieces, there is no truncation, apart for the last one of the list, or when playing one, the last 14s (in my case) of that piece are lost. The flow to HQplayer stopping, triggers HQPlayer to truncate the conversion. Not a desirable feature as this is abrupt truncation of end of musical pieces.
Easy as well to add the same delay before closing the flow to HQP upon “nothing to play next”.
Thanks for your comments and hope to see that move forward into implementation,