Roon cutting off end of tracks with HQPlayer

So ever since roon added the playhead delay for HQPlayer its created two problems.

  1. The playhead is ~10 seconds behind the actual playback time, making seeking or going back in a track a complete pain.

  2. The end of tracks are being cut off. This doesn’t occur in places where roon would be doing ‘continuous playback’ such as playing through an album. But when generally playing tracks from a playlist for example, the final 10-20 seconds or so are skipped and it immediately jumps to the next track.

PLEASE can this change be reverted? Its made using HQPlayer with roon pretty much impossible to enjoy.

@jussi_laako apologies for the tag, but i’m not sure if this is something that is a roon or HQP issue but either way I figured you might want to be aware if you weren’t already.

Video of the issue is here: https://streamable.com/6qdqaa

HQPlayer performs some compensation for the reported position. I have re-adjusted this for the next release.

What kind of filter / output rate combination are you using if it can be several seconds off?

Ah ok.
I’m using sinc-M, NS9, 192khz most of the time (to a pi2aes ropieeeXL endpoint).

Using my SMS200 Ultra with the same config gives the same level of delay.

A few other quick tests of roughly how far ahead actual playback is compared to reported position:

sinc-M, NS9, 192khz: 10.5 sec (this config also cuts the last 20 secs of audio off tracks and skips to next track)
sinc-M, LNS15, 368khz: 6 sec
sinc-M, LNS15, 768khz: 4 sec

sinc-L, NS9, 182khz: 6.5 sec
sinc-L, LNS15, 768khz: 6 sec
sinc-L, none, 768khz: 6 sec

sinc-S, NS9, 192khz: 2 sec
sinc-S, LNS15, 768khz: 2 sec

poly-sinc-xtr-lp, NS9, 192khz: 1.8sec
poly-sinc-xtr-lp, LNS15, 768khz: 1.8sec

So it seems like maybe sinc-M is the main issue? Particularly at lower sample rates. Though on all configs I do seem to have at least a couple seconds of lag between playback starting and playhead moving.
Ofc 2 sec isn’t really an issue. But 10 sec does make things a bit finnicky. The massive amount of the song that is prematurely skipped at the end is the main concern though.

Thank you for looking into this! Hopefully the above numbers help narrow it down a bit.
I’m running a ryzen 3950x for my CPU

Yes, it gets ridiculously long at low rates, with several seconds of delay. It is a bit silly filter being fixed length, intended for >= 705.6k output rates to match certain company’s silly tap numbers. sinc-S is essentially same filter but with sensible variable length (fixed delay).

Thank you!
Just updated and now the delay is only a second or so. Thank you for sorting that so fast!

I just wish Roon would update HQPlayer support, now it is stuck to v3 level… :slight_smile:

2 Likes

Ah that’s irritating.
What features would be available or different if they updated to v4? (And who do we need to nudge to make that happen? :D)

At least auto-discovery (no need to enter IP address), playback position regardless of time selection in HQPlayer Desktop main window, smooth track changes, etc.

1 Like

Have you actually opened a support request for this issue?
Dealing with the same problem.
Dirk

Updating to latest HQP version sorted it for me

Interesting comment about tap lengths by your good friend recently :grin:

1 Like

Yeah, I’m also keen to know Jussi’s take on this. :slight_smile:

:smiley:

Rob is funnily assuming that the source data he’s reconstructing is perfect… While is fact apodizing filters exist to fix the problems in source data caused by ADC and/or production decimation filters used to produce your typical PCM content.

Rob doesn’t still seem to understand source data problems. But wants to “perfectly reconstruct” distortions of the source data. In practice, your source data is rarely perfect. But instead distorted representation of the analog signal that entered the ADC. He wants to fix things by making his own ADC, but that will never fix 99+% of the source content. Majority of source data is what it is… HQPlayer can now indicate when source data is contains elements indicating such distortions and thus need for an apodizing filter to fix them.

However, there is a transient problem when you offline process individual tracks, but it is related to the excessive number of taps vs the output sampling rate. Because those transients get truncated (unless you have equally excessive lead-in and lead-out times), especially near beginning and end of a track. This is indeed something that causes distortion. If you have for example 768 kHz sampling rate, and 768000 tap filter, it needs 0.5 second “lead-in” and “lead-out”. Because the filter is one second long. Thus it causes 0.5 second delay too.

There is no relation between number of taps and whether filter is apodizing or not.

4 Likes

I still find this cutting off the end of songs annoying. Maybe it’s me who haven’t set this up properly? I have a MacMiniM1 doing Polysinc Gauss DSD256 upsampling and convolution EQ. Waiting 5-6 sec before song starts is bad but acceptable (can’t there be an option to sort of ramp up SQ/filter during the first seconds? I hate interaction lag!). Having the song cut at the end is not OK! Is this Roon, HQPlayer or pure physics?

Its an annoying problem, especially when playing from playlists with different sample rates. The problem is probably because HQPlayer reacts instantly to source changes from Roon, but due to filter and/or convolution there is a latency that means music is still playing when Roon changes source.

It would be possible to solve this by delaying source changes and caching music. Caching could also be used so for example pressing play after pause is without latency, and going from one tune to another with a different sample rate would not produce any extra latency.

1 Like

I would argue that Roon and HQPlayer are not compatible right now, despite what is being promoted. Who needs to change something, Roon or Signalyst? Or both?

That depends on how you use HQPlayer with Roon. In my use case, I have no issues. It’s pretty clear that Roon needs to update their end……

So what do you do to avoid this?

Problem gone now. I moved the Core to the same Mac as HQPlayer.

Hmm I was wondering why I never experienced this issue.

I do have Roon Core and HQP Embedded on same i9-9900K running Ubuntu.