[Fully updated from a previous post with new data and important corrections]
If I start playback with 1.186i (and not 0.9z-83 or 0.9z-9b) the following situation arises:
-- After I hit alt-E or alt-S while playing unattended, when I hit alt-P to play, the DAC has trouble synchronizing. It stutters and refuses to lock at 352 or 384. Hmmm. So I alt-x.
-- Once xxHighEnd comes back, the DAC continues with the identical improper synchronization behavior, again when I attempt playback at 352 or 384.
-- Sometimes if I play a full track at 44.1 it is possible to play again at 352.
-- A reboot solves this, but eventually, starting playback will fail again and force me to eventually go to HQPlayer or JRiver which play at 352 or 384.
On one occasion, the reboot didn’t help. This implies that I need to power off the PC to make sure the hardware is really reset.
I first thought this was a DAC problem because the upgrade is new, and so it seemed. But after I got HQPlayer and JRiver working, which did take some tweaking like explicitly telling JRiver to use 32 bit packets and increasing buffer size to 250ms, all was well, and after trying different USB cables, and now a new dedicated USB card (which I will report about soon), all attention turned to XX as the problem. The DAC maker says that synchronization is usually the fault of the data stream not being consistent enough. But how can xx be the culprit here if xx specializes in a very steady stream to avoid jitter??? Well, clearly something goes awry eventually.
What about 0.9z-83 and 0.9z-9b?
If I start with those players, I encounter no problems at all. I can play for hours. This next part is important. But if I start with 1.186i and encounter the problem I described above, then now neither 0.9z-83 nor 0.9z-9b can save the day. Also importantly, HQPlayer and JRiver BOTH save the day, that is, these two play fine even after the problem occurs. So it is as if 1.186i puts the PC hardware (not the DAC) in a configuration that eliminates all versions of xxHighEnd after the problem initially occurs.
So I went looking at the CPU utilization during xxHE playback to see what I could find. I expected to find either 0% or something very steady for jitter avoidance. Instead I see the opposite. xxHE sees 0% or 1% most of the time, but then blips of 50 to 100% occur for all processors (12) every 21 seconds or so (probably corresponding to SFS). Looking for differences with HQPlayer and JRiver, both of these have relatively stready CPU usage. HQPlayer is high, but is very very consistent.
Another clue. It may not be a synchronization problem. Instead it may be “Bad data” going out to the DAC. How do I know? Because while tweaking with XTweaks, I was able to get a solid lock on the data, but there were chunks of distorted audio every few seconds, lasting only a fraction of a second. Whereas, what I described above as a lack of synchronization where the DAC’s display alternatively displayed “------“ and “352K” and smoothly ramped the sound down and back up and everything sounded of high quality, what happened in this instance was that the DAC locked solidly on “352K” and the sound was bad. So maybe the DAC synchronizes just fine and sees invalid data and displays “-----“ and ramps down, then sees good data, ramps up and displays “352K”, in a loop back and forth and I mistakenly call it a synchronization problem.