Brian referred me to Jussi, and after ruling out all of the issues he suspected, he thinks it is something strange going on. I’ve sent him HQPlayer logs of HQPlayer playing DSD256 files with and without Roon (I can see nothing obvious on them) but haven’t heard back from him yet.
Thanks…I’ve heard from a number of people who all seem to be experiencing the same thing. Happens every time for me…so hopefully shouldn’t be too hard for Brian and Jussi to figure out. Obviously both are doing a bunch of testing before they each release the next versions. I want to do some more experimenting tomorrow to see what if any factors in the machine configurations might affect this.
Mac OS 10.11.3 / Mac Mini 2012 / Roon 1.1 build 99 / HQplayer 3.13.0b2 / Cubox-i NAA - Jussi’s 311 cubox-i build / IFI Micro iDSD - most recent firmware
DSD256 output (11289600 bit rate), any Filter, and Modulator…doesn’t matter.
DoP or no DoP
Any DSD256 file plays fine straight out of HQplayer, but stutters initially (off and on for the first 15 seconds or so) when played from Roon to HQplayer. I get the exact same thing regardless of whether I use my NAA or go straight from the computer to the DAC.
I get the same thing if I downsample the DSD256 file to DSD128 and send it to my Auralic Vega. Perfect when dropped directly into HQplayer…stuttering when played from Roon to HQplayer.
The fact that @Peregrino sees this with 352.8k files suggests that this is related to data rate, not DSD format.
I’m ignoring NAA for the time being–this issue seems to happen both with and without it. Also, if playback works through HQPlayer -> USB but not with HQPlayer -> NAA, it’s not likely to be a problem on the Roon side.
I set up a mac with an exaSound DAC today, since it’s one that we know is associated with problems. At first it was pretty stable, but after a little while, I started getting drops.
I confirmed that Roon’s buffers weren’t draining–we have at least 10s of audio in RAM at all times, and the storage (dsf files on local SSD in my case) wasn’t causing a bottleneck.
One interesting observation: if I kill Roon forcibly, HQPlayer keeps playing for a brief moment before it runs out of audio. This is about 1/2s for DSD256, and ~4s for 44.1k/16. It’s concerning that the buffer’s length (measured in time) changes based on the material–this may explain why DSD256 is less stable. I’m going to contact Jussi and see what he thinks.
Just one thing. You write:
‘Also, if playback works through HQPlayer -> USB but not with HQPlayer -> NAA, it’s not likely to be a problem on the Roon side.’
Maybe I misunderstand your point, but I thought we both said playback works through HQPlayer -> NAA, just not with Roon -> HQPlayer -> NAA; and @zorntel also said the same applied using USB direct from the computer. (I haven’t tried it without NAA because of logistics of my setup).
Ok…here is some more data, Brian and Jussi. When I run Roon from a mac and send the DSD256 file to a Windows 7 machine running HQplayer 3.12 (either connected directly to an IFI micro iDSD or via a linux NAA), the file starts right away…no stuttering. SO…the problem is either how the mac version of roon sends the DSD256 file (incidentally it still stops at the predicable place)…or how the mac version of HQplayer receives the file.
Ok last piece of information on the DSD 256 stuttering with roon. I brought up a Linux Ubuntu studio 14. 04 machine this weekend to run HQ player (3.12}. It also does not stutter when I feed it files from roon (1.1 b99} running on my Mac. So it appears to be an issue only with the Mac running HQ player when receiving files from the Mac running roon. DSD files still stop on the second track after the 3:20 roon freeze, however. All tests done using a naa on Linux with.either IFI Micro iDSD at DSD256 or Auralic Vega with DoP at DSD128.
Ultimately, HQPlayer is responsible for delivering the bits to the sound card in time to play them without stuttering, because HQPlayer owns the relationship with the hardware.
It is theoretically possible that Roon is doing something to interfere with this (like not sending data quickly enough), but we lack the visibility into HQPlayer internals that would be required to determine this ourselves.
I’ve reproduced this issue while watching our memory buffers and timing behavior, and it doesn’t look like we are having trouble delivering in time–we have rather deep RAM-based buffering (when compared to HQPlayer), and HQPlayer is in charge of controlling the data flow. None of this is 100% conclusive (because again, we can’t see inside of HQPlayer), but it is suggestive that this problem isn’t within Roon.
Jussi and I have been in communication on this (off the forums). My understanding is that he’s investigating this. I’m sure if he finds a reason to believe that Roon is holding up data transmission, he’ll get in touch.
Until then, I think the next important step is to help Jussi reproduce the issue himself under circumstances that definitively exclude possible interactions with system-level things like App Nap. If he finds an area where we need to improve, I’m sure he won’t be shy about letting us know.
In case anyone is not following the thread on the CA forum, I’ve just posted this:
After further experiments with different setups, I agree with Robert that the crucial variable is whether Roon and HQPlayer are on the same machine.
My normal setup: RoonServer/HQPlayer on the same Mac Pro 3.5Ghz/6-core/32gb RAM > Ethernet > NAA > USB DAC.
Result: DSD256 playback (with all filters/modulators) starts almost immediately but stutters badly for usually at least 10-15 seconds. Same result with and without Pipeline SDM checked.
Changing to: RoonServer still on Mac Pro, but playing to HQPlayer on a distinctly less powerful MacBook Pro/i5 2.6Ghz/2-core/16gb RAM > Ethernet > NAA > USB DAC.
Result: Longer silent pause before playback but then plays very smoothly without stutters (for all filter/modulator/upsampling within same family).