ROON / HQPLAYER stops when new track sample rate changes

My setup is Roon (NUC I5) -> HQPLAYER (I7 PC) -> microRendu(NAA) -> HUGO 2 (DAC)
I am using HQPLAYER to upsample to DSD256. No problems when all tracks are the same sample rate / bit depth, however, when this differs between tracks ROON/HQPLAYER stops at the beginning of the new track. Clicking on the play button in ROON gets playback started again.
These are my HQPLAYER settings:


image

If I just use HQPLAYER to directly play these tracks all is well, so it seems that there is some communication issue between ROON and HQPLAYER when the sample rate / bit depth changes from track to track.

Any suggestions on overcoming this?

Same problem here.
Was working fine untill latest Roon update.
As many Roon users like myself use this application in combination with HQP and Tidal it would be appreciated if the interfaces could be tested prior to update release.

Same problem here. The only difference is it stops with 2 seconds left when the next track/album is a different sample rate. I use HQP (NAA) thru ROON from a macbook air to mRendu to Gustard u12 to Devialet. This has been going on for months for me. Originally it was fine.

@Robohips / @Benno / @DJD ---- Thank you for the feedback here, the insight is very appreciated!

Moving forward, to help aide in our evaluation of this behavior you are experiencing with Roon + HQPlayer, may I very kindly ask you to please provide the following (if you have not already):

Setup Details:

  • A brief but accurate description of your current setup using this link as a guide. The points that I am most interested in are the following:

    • The make, model, and specs of the device hosting your Roon core.

    • The make, model, and specs of the device hosting HQPlayer.

    • Where your musical collection is being stored.

    • The endpoint (or endpoints) that you are experiencing the issue with and all devices involved with that (those) audio zone(s).

General Data Gathering:

  • Pease provide screenshots of…

    • Your signal path leaving Roon when the behavior occurs.

    • Your Roon settings.

    • Your HQPlayer settings.

  • Based on your feedback it seems that when Roon is left out of the equation there are no issues when upsampling. Has the opposite been confirmed? In other words if the upsampling was handled by Roon DSP engine do you make the same observations?

  • Please very briefly walk us through the steps (from a procedural stand point) that reliable reproduce the reported behavior, based on your individual usages of Roon with HQPayer.

-Eric

Roon core: Intel I5 NUC (CPU 5250U @ 1.60GHz, 16Gb RAM)
HQPlayer: Intel I7 desktop PC (CPU I7-2600 @ 3.4GHz, 8Gb RAM)
Windows 10 Pro 64bit ver.1703 is running on both PCs.
My music is on an ASUSTOR AS-202TE NAS (4Tb)
Router: ASUS RT-AC68U
The signal chain is Roon (NUC I5) -> HQPLAYER (I7 PC) -> microRendu(NAA) -> HUGO 2 (DAC)
The connections for the above are wired. I also use an Android tablet wirelessly to control Roon.



image

Yes, that’s correct.
These are my observations:
Roon -> mRendu - no issues
HQPlayer -> mRendu - no issues
Roon + HQPlayer -> mRendu - when all tracks are same sample rate - no issues
Roon + HQPlayer -> mRendu - when next track has a different sample rate than the preceding track play stops at the beginning of the new track

I have just tried using Roon DSP to upscale mixed sample rate tracks to 192kHz going to HQPlayer and there are no issues with this.

Basically just add tracks with differing sample rates to the play queue. I have found that occasionally, 3 or 4 tracks will play
OK then will stop on the next track. More normally though the behaviour will begin at the first track with a different sample rate to the previous track.

Hi, encountering this issue after updating Roon/HQPlayer to the latest version. I recall this happening a while back and the issue was fixed, but it has now come back…anyone else experiencing this? Thanks.

I moved your post hammer.

Cheers, Greg

I replicated this setup nearly exactly here (Roon on NUC -> HQPlayer 3.18.2 on Windows -> NAA -> Hugo), and replicated your HQPlayer settings directly.

I tried a few transitions amongst 44.1kHz, 96kHz, and 192kHz source material, in all directions, but never saw playback stop/fail. Is there another combination that is necessary to trigger this? Alternately, is this a problem that happens only intermittently (meaning–I may need to do a much larger number of transitions to see it)?

The first step to figuring out what is going on here is figuring out how to replicate the problem. Then we can figure out whether someone over here or @Jussi_Laako needs to look into this next.

Sometimes it will be OK for around 30-60 mins and then stop. Other times it will happen straight away. However, once it happens it will happen consistently.

In 30-60 minutes, how many transitions do you think are happening?

If you’re playing whole albums the answer is likely no more than 1. If you’re transitioning on every track it could be 20. Trying to figure out how long to test before concluding that we’ve failed to replicate the issue.

Hi Eric,

I would like to thank you for your very fast reply and taking our problems serious, this is really appreciated and indicative for the service Roon is providing to it’s customers.
(Un)fortunately I’ve not been able to reproduce the error last night (testrun of 1.5 hours).
I’ll keep you posted.

Kind regards,

Benno

1 Like

When I reproduce this issue I queue around 15 tracks of alternating sample rates. Start the first track playing, then to speed things up I progress the cursor to near the end of the track, say with 10-15 secs left to play and let it transition to the next track. I would expect that if you were to reproduce the stop it would happen within the 15 tracks.

Hi @Robohips — Thank you, as well as others in this thread (@Benno and @DJD), for the followups and continued insight :thumbsup:

My apologies as I should have asked this in my initial post :dizzy_face:, but can you please verify for me what version of HQPlayer you are implementing and when (roughly) the application (HQPlayer) was last updated.

-Eric

I just delivered my amps to fedex to send back to Devialet for the new streamer board so I am out of commission for a couple weeks. I was using the latest HQP and ROON versions though. I’ll try when I get the amps back and report back here.

1 Like

I set up a looped, mixed format queue (each track different from adjacent), and did 2 things:

(1) Listened for 2 hours
(2) Did 40 manual transitions as you describe (seek to 10 seconds from end, let it transition) in a row

Unfortunately…no issues. It worked fine. I’m thinking there has to be another ingredient here.

Nothing actually changed about Roon<->HQPlayer in the latest release…so I’m starting to think that maybe this was brought on by something environmental.

Doesn’t mean there isn’t a bug here, but without seeing it, it’s hard to make forward progress. Any other ideas how we might make this happen?

Also worth noting that the first post in this thread was from 24 hours before the latest release, so yeah – something else is almost certainly going on here.

1 Like

Yes - this is the finest conclusion I suppose… and anyway, is HQPlayer really necessary when there is already fully functional Roon DSP?

For many people, yes. That’s why we’re working to try and pin this down :slight_smile:

In my setup, I only get the error when Roon Server is running on a machine that is different than the machine runnng HQPlayer. If both are on the same machine, then the transition to the next song at a different resolution is fine. In both instances, my DAC is connected directly to the Windows 10 PC running HQPlayer. DSP is enabled on Roon and HQPlayer is outputting DSD256 is both scenarios.

Running HQPlayer 3.18.2

The error I see when the music stops is something like Roon has lost connection to transport.

This matches my environment. Roon on ROCK NUC, HQP on Windows…but what you might really be saying is that this issue is performance or timing dependent. Things on the same machine usually happen faster, and with more predictable order/timing than things over a network.