I understand why there is a delay after hitting play. it takes some time for HQplayer to do the processing to get to the point it is ready to output sound. The song starts and the progress bar advances but no sound is coming out until the processing gets ready, so sound is always X seconds behind what the Roon progress bar says. In my case about 6 seconds.
The problem is at the end. The song of course needs to keep playing for the same 6 seconds after the Roon progress bar gets to the end to get to the end of the song… BUT… once it gets to the end of the progress bar , Roon starts loading the next song, which cuts off the end of the song that is still finishing that last 6 seconds.
Is there a fix other than using a different HQplayer filter that doesn’t cause a delay.
That filter doesn’t work that way on my system…for example, when I play “The Wall” by Pink Floyd, there are no cutoffs or delays and I hear all of the songs.
All Redbook CDs are made in DAO (Disc At Once) mode and are gapless. Each track plays from beginning to end and on to the next track with no gap. Now, those tracks may or may not play sound to the very end of the track or play sound from the very start of the track. Almost all digital music these days comes as gapless. Especially albums that count on gapless playback to sound correct.
The CD “The Wall” does play sound to the very end of the track and continues at the very beginning of the next track.
Roon, and HQPlayer, supports this gapless playback whether or not the album takes advantage of it like “The Wall” does.
I tested with “The Wall” because it is easy to tell if there are any issues with tracks ending or starting incorrectly. I tried Bob Dylan’s “Blonde on Blonde” album too as the tracks create their own gaps between tracks and saw no issues with tracks ending early, starting early, or starting late.
If you don’t know that “The Wall” needs gapless playback to sound correct, you really should add it to your library…
The problem is not one of being gapless. It is one of the end of the track being cut off. So that example does not fit the fault being reported. This is much more likely to be about the way HQPlayer has been integrated into Roon and what hardware is being used. Adjusting the delay settings might have an impact but I can’t test that not being a HQPlayer user.
I should have been more specific. I’m not talking about playing an album through to the end… that works fine. It is when one album ends and another begins, or even more specifically … I listen to Roon radio a lot where every song is on a different album.
Long filters have a long delay, especially the fixed length ones like sinc-M if used at low output sampling rates.
Tail cut offs are related to a case where source format changes and the way Roon uses HQPlayer. Since Roon doesn’t use HQPlayer’s playback queue, it instead stops HQPlayer and then asks to play another item. HQPlayer doesn’t know why it was asked to stop. If source format doesn’t change, this doesn’t happen and the track tails are not cut off either.
Kind of strange way to “fix” Roon’s way to use HQPlayer. Roon should be finally fixed to use HQPlayer’s playback queue correctly, and also the automatic HQPlayer discovery would be very nice for HQPlayer hosts that are using DHCP instead of having to enter IP address. Especially because there’s no way to edit the entered IP address in Roon, the entire endpoint needs to be deleted and created new if IP changes.
