• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

HQplayer - do I need it?

gvl

Major Contributor
Joined
Mar 16, 2018
Messages
3,427
Likes
3,982
Location
SoCal
No audible dropouts

No measurable jitter

How would this "issue" manifest in your opinion?

In practical terms we are talking about literally a non-issue

I think we should at least acknowledge that it technically exists. If you play long enough there will be a dropout, but it may take a whole day, so yes not a practical issue but an issue nonetheless.
 

gvl

Major Contributor
Joined
Mar 16, 2018
Messages
3,427
Likes
3,982
Location
SoCal
Buffer under/overflow isn't an issue when using the SPDIF interface for the reason cited in my earlier post. Underflow/overflow isn't an issue when streaming to a USB audio interface because its internal sample clock is used to pace the DAC samples in that use case. The host need only provide data via USB sufficiently fast to keep the audio interface's output buffers partially full (never empty, nor full) during playback. Unless the output buffers are set to a pathologically-small size (e.g. to mitigate latency), even a 12 Mbps USB2 interface provides ample bandwidth for contiguous audio renders.

I sense lack of understanding of technicalities on your part. Again, it has nothing to do with jitter. Even with a perfectly recovered stable clock on the spdif receiving end its frequency is never exactly the same as the clock that the receiving USB async interface is running at. If it’s higher you end up with overflow because USB can’t keep up with the source, if it’s lower you get underflow as spdif can’t keep up with the USB sink. It will take a while for this to occur as the issue is mitigated by rather large buffers in HQP at the cost of added latency. If you don’t believe me you can ask Jussi himself.
 

NTK

Major Contributor
Forum Donor
Joined
Aug 11, 2019
Messages
2,660
Likes
5,820
Location
US East
I sense lack of understanding of technicalities on your part. Again, it has nothing to do with jitter. Even with a perfectly recovered stable clock on the spdif receiving end its frequency is never exactly the same as the clock that the receiving USB async interface is running at. If it’s higher you end up with overflow because USB can’t keep up with the source, if it’s lower you get underflow as spdif can’t keep up with the USB sink. It will take a while for this to occur as the issue is mitigated by rather large buffers in HQP at the cost of added latency. If you don’t believe me you can ask Jussi himself.
The technology to address the clock drift issue already existed 30 years ago. You can refer to this Analog Device article.

Basically, it is implementing the below analog equivalent in the digital domain. The input signal and clock is retrieved. A D/A conversion is performed, and if a sample rate conversion is required, the signal is either anti-image filtered (for up-conversion) or anti-alias filtered (for down conversion). Then it is resampled with an A/D conversion at the new clock rate.

All the conversions are implemented in the digital (computational) domain, and no actual analog conversion step is involved. There is also provision to address the problem of input clock drift.
analog.png
 

gvl

Major Contributor
Joined
Mar 16, 2018
Messages
3,427
Likes
3,982
Location
SoCal
The technology to address the clock drift issue already existed 30 years ago. You can refer to this Analog Device article.

Sure, but I don’t think HQP is running ASRC, it has a couple of async filter selections if memory serves, so perhaps it can but not with every filter. And ASRC is not bit perfect which will turn off some of the posters in this thread.
 

NTK

Major Contributor
Forum Donor
Joined
Aug 11, 2019
Messages
2,660
Likes
5,820
Location
US East
Sure, but I don’t think HQP is running ASRC, it has a couple of async filter selections if memory serves, so perhaps it can but not with every filter. And ASRC is not bit perfect which will turn off some of the posters in this thread.
It is done in the DAC chip.

ess.png
 

NTK

Major Contributor
Forum Donor
Joined
Aug 11, 2019
Messages
2,660
Likes
5,820
Location
US East
The on DAC chip ASRC, if any, is irrelevant to the point I’m trying to make. ESS chips run on yet another clock in async mode.
No difference if the digital signal goes into a SPDIF interface. This is a general technique to decouple the source clock from the data, i.e. to re-clock the signal.
 

Keith_W

Major Contributor
Joined
Jun 26, 2016
Messages
2,531
Likes
5,803
Location
Melbourne, Australia
Does correct sample rate switch automatically? Or manually?

I don't want Windows in any of my daily listening

I boot headless HQPlayer . By the time i sit on my couch I can get music going with just my iPad

User experience is important to some people

JRiver switches sample rate automatically. This is a screencap of the relevant setup page.

1679963767026.png
 

jhenderson0107

Active Member
Joined
Jun 10, 2021
Messages
191
Likes
439
Location
California
I sense lack of understanding of technicalities on your part. Again, it has nothing to do with jitter. Even with a perfectly recovered stable clock on the spdif receiving end its frequency is never exactly the same as the clock that the receiving USB async interface is running at. If it’s higher you end up with overflow because USB can’t keep up with the source, if it’s lower you get underflow as spdif can’t keep up with the USB sink. It will take a while for this to occur as the issue is mitigated by rather large buffers in HQP at the cost of added latency. If you don’t believe me you can ask Jussi himself.
The audio stream is either being sent to the audio interface via SPDIF or USB during any given session. Not both. If the former, then the clock recovered from the SPDIF data stream dictates the sample rate. If the latter, the internal clock of the interface dictates the sample rate. I've outlined how buffer over/underruns can be avoided in both instances. Jitter and any possible reduction techniques employed on the interface are irrelevant.

Perhaps we're just talking past one-another and I just don't understand the test conditions under which you foresee buffer over/underruns occurring.
 

Keith_W

Major Contributor
Joined
Jun 26, 2016
Messages
2,531
Likes
5,803
Location
Melbourne, Australia
I think we should at least acknowledge that it technically exists. If you play long enough there will be a dropout, but it may take a whole day, so yes not a practical issue but an issue nonetheless.

I get dropout if I play music for an hour or less. I sometimes settle down with a playlist and after some time, I start to hear music skipping as if the disc was poorly ripped. All I need to do is stop playback and restart it, and the problem disappears. (This is with JRiver).
 

gvl

Major Contributor
Joined
Mar 16, 2018
Messages
3,427
Likes
3,982
Location
SoCal
Perhaps we're just talking past one-another and I just don't understand the test conditions under which you foresee buffer over/underruns occurring.

I was talking about HQP embedded reading stream off spdif input, doing its processing, and sending the resulting stream to a DAC over USB.
 

Music1969

Major Contributor
Joined
Feb 19, 2018
Messages
4,642
Likes
2,811
I get dropout if I play music for an hour or less. I sometimes settle down with a playlist and after some time, I start to hear music skipping as if the disc was poorly ripped. All I need to do is stop playback and restart it, and the problem disappears. (This is with JRiver).is bad

Something is wrong with your setup - this is broken

I play for many hours on weekends

Never experienced a dropout feeding SPDIF into HQPlayer

Headless HQPlayer Embedded for the win again !

I wouldn't use it if I had dropouts
 

Music1969

Major Contributor
Joined
Feb 19, 2018
Messages
4,642
Likes
2,811
JRiver switches sample rate automatically. This is a screencap of the relevant setup page.

View attachment 275316
This only shows me that you can choose what the output should be for each input

This could be manually changing input sample rate

It doesn't mention automatic sample rate switching

So you can play Qobuz and choose exclusive mode and you can see sample rates changing correctly in JRiver?
 

Keith_W

Major Contributor
Joined
Jun 26, 2016
Messages
2,531
Likes
5,803
Location
Melbourne, Australia
This only shows me that you can choose what the output should be for each input

This could be manually changing input sample rate

It doesn't mention automatic sample rate switching

So you can play Qobuz and choose exclusive mode and you can see sample rates changing correctly in JRiver?

Yes, it changes automatically. As the screen shot shows, you can set any input sample rate to be automatically converted into any output sample rate. No manual intervention is required. I can't see JRiver showing me that it has switched sample rate, but I can see my DAC changing the sample rate.
 

Music1969

Major Contributor
Joined
Feb 19, 2018
Messages
4,642
Likes
2,811
Yes, it changes automatically. As the screen shot shows, you can set any input sample rate to be automatically converted into any output sample rate. No manual intervention is required. I can't see JRiver showing me that it has switched sample rate, but I can see my DAC changing the sample rate.
The screenshot doesn't actually show you that (example) Qobuz track at 48kHz has been sent to JRiver at 48kHz

Looking at your DAC only reflects what your settings are.

HQPlayer shows me the actual incoming sample rate.

So my RME input sample rate and HQPlayer input sample rate always match automagically
 

Music1969

Major Contributor
Joined
Feb 19, 2018
Messages
4,642
Likes
2,811
I guess if you set a different output rate for different inputs, this would let you use the DAC rate to workout correct auto sample rate switching

That is more useful than just looking at the settings page

Still, i don't need to use Windows daily for music listening
 

Keith_W

Major Contributor
Joined
Jun 26, 2016
Messages
2,531
Likes
5,803
Location
Melbourne, Australia
The screenshot doesn't actually show you that (example) Qobuz track at 48kHz has been sent to JRiver at 48kHz

Looking at your DAC only reflects what your settings are.

HQPlayer shows me the actual incoming sample rate.

So my RME input sample rate and HQPlayer input sample rate always match automagically

1679968754696.png


If you hover your mouse over the button highlighted in blue, JRiver pops up a little box indicating the input and output sampling rate. It does all this automatically without any input from me. In fact, I am not aware of ANY software that requires you to manually change the sampling rate for output to match the input every time you play a different file.
 

Music1969

Major Contributor
Joined
Feb 19, 2018
Messages
4,642
Likes
2,811
View attachment 275338

If you hover your mouse over the button highlighted in blue, JRiver pops up a little box indicating the input and output sampling rate. It does all this automatically without any input from me. In fact, I am not aware of ANY software that requires you to manually change the sampling rate for output to match the input every time you play a different file.
Of course I'm not talking about music files!

I'm talking about WASAPI input from SPDIF source !

That's what we have been discussing
 

jhenderson0107

Active Member
Joined
Jun 10, 2021
Messages
191
Likes
439
Location
California
I was talking about HQP embedded reading stream off spdif input, doing its processing, and sending the resulting stream to a DAC over USB.
Thanks for clarifying. I agree with you and apologize for replying out of context. In that specific case, synchronization would require that the recovered SPDIF clock be exposed to an external output (BNC) and used to drive to the master clock input on the USB DAC. If that capability is unavailable, contiguous playback cannot be guaranteed.
 
  • Like
Reactions: gvl

gvl

Major Contributor
Joined
Mar 16, 2018
Messages
3,427
Likes
3,982
Location
SoCal
Of course I'm not talking about music files!

I'm talking about WASAPI input from SPDIF source !

That's what we have been discussing

Going by memory the only way JRiver can take external audio stream in is through Asio and it requires a manual sample rate selection. It does come with a virtual WDM driver that makes JRiver appear as audio device that Windows apps can output to, given it support’s Wasapi exclusive mode I think it’s reasonable to expect automatic sample rate detection is supported in JRiver via this route. There may be a way to route an spdif input to this WDM driver through some sort of virtual cable and have rate detection working, but I haven’t tried.
 
Top Bottom