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.
-
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?
- Thread starter MisterDee
- Start date
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 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.
Keith_W
Major Contributor
JRiver switches sample rate automatically. This is a screencap of the relevant setup page.
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
I was talking about HQP embedded reading stream off spdif input, doing its processing, and sending the resulting stream to a DAC over USB.
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
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
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
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
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
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
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.
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.
