Latency and GUI discussion

Just for fun I tried using Roon endpoint with my room-correction convolution file from Roon. To sum it up shortly, here are the differences I noticed:

  1. The lack of latency is nice (but that also makes me question Roons implementation of convolution file, a 131k taps convolution file should have some latency, but none at all in Roon). @jussi_laako @brian comments?
  2. The sound became softer and sounding less dynamic, but also more forgiving and easier to listen to, especially on bad recordings. I could not detect any changes in sound stage.

This is in comparison with using Roon -> HQPlayer -> NAA, up-sampling to 768khz with short-mp filter in HQPlayer, and using the 96khz 131ktaps convolution file from HQPlayer instead of in Roon.

Here are some latency comparison, which I did by pausing in the middle of a 44.1khz tune and measured between pressing play and music starting:

  • Roon no up-sampling and 131ktaps 96khz convolution: 0.1 seconds
  • HQPlayer using “none” as up-sampling and no convolution: 1.5 seconds
  • HQPlayer using “none” as up-sampling and 131ktaps 96khz convolution: 3.5 seconds
  • HQPlayer using short-mp as up-sampling and 131ktaps 96khz convolution: 4.5 seconds

All hardware are of course the same, in my case an RME ADI-2 DAC and upgraded microRendu as endpoint running either NAA or Roon bridge, 1Ghz ethernet. The latency problems is, in my opinion, the number one problem with HQPlayer.

How do you measured that? This is my latency with polysinc-xtr-lp. I just want to understand how you can say that HQPlayer is the number one problem, because its not.

Can you post latencymon scores with drivers tab included.

EDIT: This is ASDM7EC DSD256 polysinc-xtr-lp

Its the period of time that passes after you press “Play” in Roon and until the music starts. Just measured it with a desktop clock, so not 100% accurate. The latency you measured is in micro-seconds on a OS level, and is not related.

Can you make test with latencymon and post scores?

You are talking about two entirely different things. @Magnus is talking about audio delay due to algorithms and buffers, while @Koffi is talking about interrupt scheduling latency (which is OS feature).

Why the delay is problem?

If you want to compare delays, try HQPlayer standalone and Roon standalone. Because there is quite a bit of streaming buffer too between Roon and HQPlayer, because Roon cannot guarantee steady delivery of data. This buffer was increased somewhat recently because Roon became more unpredictable especially when streaming from Tidal.

NAA also has some extra delays compared to playing from HQPlayer directly.

Pause implementation was changed during spring to deal with cases where software volume control is used as only volume control means. Some DACs had pop/click problems when full gain power amp is directly connected, this change dealt with that issue. Side effect is about one second delay for pause.

Also depends on how the pausing is done. If you do it from Roon, it works in a different way than in HQPlayer. Because Roon doesn’t make conceptual difference between pause and stop.

About 1 - 1.5 second delay is on purpose.

1 Like

I think you’re right. I think in Finland we have to good internet connections and I cant relate to this problem.


I tested with convultion in roon & hqplayer it doesnt make any difference for me.

We where talking about using Roon with or without HQPlayer, so of course I use Roon to measure latency, latency using HQPlayer directly is not interesting for me (or others on this Roon forum).

And if Roon can stream Tidal (which I used when measuring latency) in a safe way to its Roon endpoint over network with only 0.1 seconds delay, it should be possible to stream with same delay to HQPlayer (especially in my case where Roon and HQPlayer are on same host).

According to rePhase, a 131ktaps 96khz file would have 0.6 seconds delay, but the difference with and without that convolution file in HQPlayer is 2 seconds (1.5 seconds to 3.5 seconds). So correct me if I am wrong, but it can be improved upon in HQPlayer.

Its not making any latency for me if Im running HQPlayer via Roon or Roon, its your connectioncs or hardware.

Okay, its making that 1-2s. :smiley:

Yes, and thats without using convolution file in HQPlayer (its not enabled in your video). And also, it depends a lot of frequency and number of taps of the convolution file.

Last video was made when windows was in balanced mode. Why the latency at start is problem because its only when you start playing? If you add songs to queue or let roon radio play there is no problems anymore after that.

Jussi explained why already in his post above. Read it again…

1 Like

No, he did not explain why the convolution file below has a 2 second delay in HQPlayer, when it should have less. And if Roon can play from Tidal with a 0.1 second delay to its endpoint, why does HQPlayer need 1.5 second to stream to its endpoint?

At the very least, some visible buffer settings on the NAA so one could experiment would be nice.

The reason I nag about this is that I usually have about 5 seconds delay in total, and when someone walks into the room or the phone rings, 5 second feels like an eternity (I listen to music in my office)!

In that combination you always have Roon’s delay, plus HQPlayer’s delay when it is play. With HQPlayer it certainly cannot be less than with standalone Roon.

Your pause test doesn’t tell anything about any other delay than difference in how pause is implemented. Sure this is different, like many other things too. In addition to Roon doing pausing in a different way with HQPlayer than HQPlayer alone would do (because it stops HQPlayer’s engine completely).

Roon is not horribly interested in improving and updating the way it uses HQPlayer.

How do you measure delay from Tidal server to Roon endpoint? I’m pretty certain it has much more delay. Again, trying how quickly playback pauses doesn’t tell anything about the delay itself.

131 taps at 96 kHz; 131000 / 96000 = 1.3646 seconds

Why does this matter? The implementation is the way it is for sound quality reasons.

1 Like

I’m still curious how do you test how long it takes from Tidal server for data to reach Roon endpoint.

Because it has large FIFO buffer for a reason.

I just hit amplifier’s mute button from remote control. (although my phone never rings and nobody never walks into my office :smiley: )

1 Like

After first load I dont have any breaks or anything, even I use same time 200 tabs at chrome.

Yes, my measurement is very basic, but its the way I notice the delay when using Roon + HQPlayer. In fact, the Roon-tidal communication in itself is not relevant since that will be used no matter if I use Roon with HQPlayer or without. What is interesting though is Roon -> Roon endpoint which seems to have far less latency than HQPlayer -> NAA endpont on same hardware and network.

I know that all this is not in your hand, Roon also needs to be involved to get it better. For example a “PAUSE” command would mean you could halt the playback without emptying buffers which could drastically reduce delay when pressing play again (CONTINUE command).

Roon seems to have taken a 1 year vacation though, sorry to say but a “sleep timer” is not exactly stellar result for many months of development. And when was the last time Roon did anything related to sound quality?

What they need to do for music quality? Can you please tell.

Lots and lots, but this is not the thread for that. Check this thread for example:

If you think Jriver or Audirvana sounds better than HQP+Roon youre not using it right. But you answered to question by givin just another thread. What they can make better?

EDIT: Im not working for Roon, I just want to know bcuz I think I have tested all possible combinations and I think there is no even fight about that HQPlayer sounds best. Roon has best software so what do you get when you 1+1 ? And if you know better combination let me know so I can test it now.