Roon controlling HQPlayer causes Pops between tracks

I’ve have poorly written ASIO DAC drivers that can cause popping on DSD256 playback stop from Roon or HQPlayer. I can live with this but when Roon controls HQPlayer I get the same issue when I jump around to different songs or positions in songs.

  1. No issue when roon is used alone unless I come to a full stop.
  2. No issue when using HQPlayer alone unless I come to a full stop.
  3. The issue only occurs when controlling HQPlayer from Roon.

@brian, @jussi_laako is Roon forcing HQPlayer into a full stop and start when I jump around tracks from the roon interface?

@brian If I hit pause in Roon first and then play the next track I get no bad audio driver pop. Could roon do something similar by default?

Yeah, we are doing the equivalent of pressing “Stop” on HQPlayer when it’s time for Roon to start a new stream.

When the integration was young, we attempted to make this smoother by queueing the next track and pressing “Next” instead of doing “Stop” “Clear Playlist” “Play”, but there were a lot of problems where the system would get wedged with Roon in a state where it thought HQPlayer should be playing, but HQPlayer not playing. This approach is a little bit clunkier, but doesn’t have those reliability issues.

With Roon alone, we own the device relationship, and we have behavior in place to minimize release/re-acquisition of the device. HQPlayer has a different set of rules that accomplish mostly the same thing. The problem is–when they are put together there’s no way for Roon to express to HQPlayer at the time of our “Stop” command that it’s about to get another track, so it always does a full stop.

If we get a lot of feedback on this, we can try making the old/smoother way work again. Maybe both pieces of software are more stable now and it will go better. At the time, it caused a lot of support issues.

I guess I though it would be an easy implementation because simply hitting pause in Roon first eliminates the pop when selecting the next track. But I’m probably wrong.

Hm. That result doesn’t totally make sense–we’re doing the same “full stop” regardless of whether we were paused or not I think. Maybe something is going on differently on the HQPlayer side?

So pause still pauses HQPlayer but as soon as I select the next track it sends a full stop and then initiates a new play?

@jussi_laako Do you have any feedback on this?

Yes, that’s right.

I checked this case and the only difference is that with pause->next case there’s the intermediate pause before stop. Pause meaning that silence is being played. While when stop is issued straight from play state, the engine just stops quickly as possible.

This stop-start cycle in itself is of course unnecessary and quite heavy operation.

I also checked my engine logic, and at the moment Next/Previous/SelectTrack cannot be called from paused state (just ignored). That shouldn’t be hard to change though because Paused state is so similar to Playing state.

Thanks @jussi_laako, hopefully you and @brian can work out a solution. I don’t hold much hope in McIntosh actually fixing their driver. I know there are a few other DACs with crappy drivers, those owners might appreciate it as well.


Actually I already changed so that Next/Previous/SelectTrack can be issued also in paused state and will be in next release…

1 Like