HQPlayer doesn’t know if the “Stop” command from Roon is because you actually wanted to stop the playback. Or because it just wants to proceed to the next track (in which case it is totally unnecessary thing to do)… Because at that point Roon has not yet told about what it is going to do next. There is no indication of the intention.
Yes, as I mentioned earlier you need a “transition-stop” for 2 and 3, which should only be used between tunes with different sample rates. Then HQPlayer can minimize what needs to be done. Once thats done step 2 should be easy, I imagine step 3 will be complicated though.
This “transition-stop” wouldn’t do anything at all. So it is unnecessary thing that can be skipped.
If Roon would do what I’ve proposed, this would happen already. Except that there’s nothing to “reset”.
As long as it will work, as @brian said Roon at that level don’t know about next tune until it starts, so it will have to add the next song to the HQPlayer playlist when it starts playing it. Then HQPlayer have to make sure you don’t run into any mismatch so it ends up playing something else due to corrupted playlist.
Btw, would it be possible to also send volume information at the same time (LUFS or whatever) so HQPlayer can implement volume levelling? You typically have to modify volume in HQPlayer anyway, and I hate to do DSP in 2 software if it can be done in one only.
That should be done without explicitly stopping HQPlayer, unless you as user really want to stop playback.
Roon can always also check what is on HQPlayer’s playlist/queue.
Yes, Roon could do that if it would want to.
1 Like
I’m not concerned about what happens when people button-mash while Roon is doing stuff.
I am concerned about race conditions that will break during normal use of the product–like HQPlayer racing to advance the track against Roon needing to update it, or HQPlayer’s advance racing against Roon checking what is in the queue.
There’s no perfect way to shove a player like Roon into a UPnP-style transport API like HQPlayer. The best way we’ve found is to behave like we are the only client/manipulator (stepping away if we see evidence of others), and perform commands in a sequence where we are never racing against anything going on inside of the transport. PlayNextURI violates that principle. Our current method does not.
HQPlayer is a media player on a computer, not a black box. The stop button says “stop” not “standby”. The concepts and behavior of media player software are well understood and standardized. We shouldn’t have to imagine the product as a DAC with a long delay line and mis-labeled buttons in order to understand what’s going on.
The best user experience that can arise from this situation is if HQPlayer starts reporting time positions and transitions consistent with what the user is hearing.
The idea of using PlayNextURI is a distraction from the issue at hand–sure it is faster and you want us to use it, but it has other problems, and only addresses a subset of the problem at hand in this topic. We are not going down that road.
I suggest fixing the underlying issue here–that the presentation clock is out of line with your transport/playhead. The issues that people are actually complaining about in this thread all lead back to there.
Well, it is racy and doesn’t even achieve what you want.
It doesn’t… It combines multiple actions into one atomic operation.
HQPlayer is not your ordinary media player. It is rather an advanced DAC firmware.
No, it is your insistence into using ancient v3 API functionality rather than the new v4 one that fixes many of the issues encountered over the years. Playback time information you get is just for user display purposes. It shouldn’t be used for anything playback related.
But anyway, I’m tired of arguing about this topic. I guess this functionality won’t get fixed or any other HQPlayer related either.
How about a compromise:
- Roon stops sending stop/reset between tunes with different sample rates, just starts the new tune when old one is finished.
- HQPlayer handles things internally in whatever way is best whenever the sample rate has changed from the last played stream (for example by adding it to internal playlist).
- (if needed for backward compatibility) Roon adds a “Support old versions of HQPlayer” toggle which if on then Roon sends the stop like today.
Its a rather basic and annoying problem, and its not like we are talking about many hours or work, so it should be possible to solve. And if volume information could also be sent, it would be a nice added bonus (so HQPlayer can do proper volume leveling).
I wish this would happen… Including the case when last item is encountered. HQPlayer will stop by itself once things are finished.
This already happens.
Even more importantly - HQPlayer auto-discovery so that it is not mandatory to enter IP/hostname (or if hostname is there, it is not relying on DNS but instead discovery).
From your answers it sounds like all Roon needs to do is stop sending “stop/reset” between tunes with different sample rates. Is it that simple?
I, and I am sure all the other HQPlayer users that use Roon, would appreciate it if you and @jussi_laako could find a way to work together to improve the Roon/HQPlayer experience instead of fighting about it. I can tell you right now that for me, if it came down to a choice between Roon and HQPlayer, HQPlayer would win. The sound quality I get using HQPlayer with Roon destroys what I get from Roon by itself.
Please work it out! It seems like you want the Roon/HQPlayer interface to stay the way it was the day it was integrated and never move forward with the times. Almost like you want to sabotage it. Please tell me that is not the case!
4 Likes
If you want to nicely proceed from one stream to another, you add the next one to the playlist with queue flag set - meaning that the item will automatically disappear once it has been played.
If you want to transition immediately, you call Next to proceed to the new item. But for such case PlayNextURI is much better, because it makes sure that regardless what HQPlayer state is (playing, stopped, etc), or what ever is on the queue currently, it will start playing the new URI.
But Roon already does this, from my understanding. And if not, it should be an easy fix since it cannot do it until end of previous tune so its basically only one tune thats queued at a time.
Maybe pressing Next in Roon can also be improved, but thats another issue.
We like the v4 changes in general, just not the PlayNextURI/queueing proposal. It isn’t compatible with how Roon works and will create new reliability issues for the integration. I’ve explained the technical reasons above and where they are coming from, and those objections are not going to change.
However, I’m open to other low-impact fixes for this problem. I’m also open to moving the Roon/HQPlayer integration forward in bigger ways. We certainly are not trying to sabotage HQPlayer.
The deeper issue here is that Roon and HQPlayer each own a play queue and a set of transport controls. Roon emphatically avoids stacking one queue/transport on top of another because it is inherently shaky and is prone to issues.
This is one reason why we do not support Roon on top of UPnP devices. We have built systems like this in the past, and we know from experience that they don’t end well.
I’ve reached out to Jussi privately with some paths forward. Ultimately it takes two to tango, so I can’t make any promises. There are many improvements that I could imagine to the Roon and HQPlayer integration. Let’s see if we can make some progress.
13 Likes
With pink glasses on I would really like to see a true full integration of HQP up sampling capabilities within Roon.
This would be so much better then having the handshake between the 2 players.
Roon already has an upsampling section. I would be extremely happy if I would be able to pay for an extra license that will open up the long list of HQP filter and upsampling options on top of the 4 generic ones that come with Roon.
Play nice 
All I know is these two used to work together like clockwork. Something changed and now they don’t. Ropieeexl added naa and it was perfection and then it stopped working after 1 or the other updated. Can’t say which one but I think you know who you are. We need a HQPlayer compatible Roon Version or a Roon compatible HQPlayer version.
They still do. Problems come with some extremely long filters, especially when used at rates they are not designed for. Before those filters existed, it was harder to create those problems.
Let me try that.
So this is what I am using FFT,RPDF, PCM 2x upsampling.
Symptoms unchanged. Roon does not show any progress on playbar. The play/pause icon is correct, the progress bar never moves while the song is playing. I fully expect the 2nd symptom to occur as well, which is, playback stops after 2 songs, radio selected or unselected has no effect.
Which version of HQPlayer do you have? Are there any errors shown when playback stops? HQPlayer license is valid?