352/384 Synch or data issue initiated by 1.186i "beta-beta" after stop or pause

[charliemb]

[Fully updated from a previous post with new data and important corrections]

Hi Peter

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. 

Clues:

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.

[PeterSt]

Charlie, let me try a couple of things (for explanation) :

The synching as you call it is not in order. So, we are not talking CD players which must (PLL) "lock" or something.
This part of the subject is dead easy : when the stream is not sufficently fast applied, the DAC will have troubles. This easily includes not being able to see the 352.8 (etc.) data rate.

It will be the DAC acting strange.
But don't get me wrong here. The DAC works all right, but if it's given some difficulties it can't recover. THis is two folded :
1. The driver messes up (this is PC related);
2. The DAC itself messes up because of #1.
After this the trouble shouting gets a bit tough.
Regarding this you can try to figure out what exactly applies the "recover" which in my opinion can be found by a (sequence) combination of :
a. Pull the USB cable and replug it;
b. Switch off and on the DAC.
Notice that b. implies a. but will go a little different.
Combine this with your reboot helping *and* not helping.

XXHighEnd is doing nothing strange here, but you yourself actually can easily. This is about overdriving the things like a too low SFS, a "wrong" buffer size" (whatever that is), and a combination with the driver's buffer size and what you set in XXHighEnd (Q1, xQ1, Device Buffer Size).
Notice that only the driver's buffer size is unrelated when other players work and XXHE does not. Or should I say "related" ? I mean, it will be the only thing you won't be changing (and a player won't touch it).

Next thing is more complicated;
At testing this all, you should have "Always clear Proxy before Playback" active in Settings (Memory and disk utilization section). Also have "Include Garbage Collect" inactive (same section). Why ? because these make the difference (or can make) between XXHighEnd and other player's playback *regarding* the Alt-e behavior. Same thing with the Playback Drive (don't use one) and not having "Copy XX-drive by standard" active. But use WAV for testing.

The latter paragraph is only theory for where the differences may occur, so I am attempting to let you compare apples with apples (XXHE vs other players). But in all circumstances it will be the PC being too busy with things when you have those settings the other way around, and that in itself causing the stream to be not continuous (because that's in the end what is happening).
Example which hopefully speaks : when this Clear Proxy thing is not active, all will thus work from "caches" and it means that all had been put ready (from the last playback attempt) and in one big bang all can be done, and while the PC needs to recover from that big bang (clearing just used memory etc.) audio also starts playing. And *now* depending on a million other things, this works or it does not. When the proxy is cleared in advance, it takes longer and the recovery actually can start right away (PC performing I/O and CPU can dio a few things meanwhile).

The real life example is simple :
When I AI-upsample to 705.6 the playback is so so tough because of so many bytes to read from the source (RAMDisk in my case) that the PC (OS) never gets round to any recovering, and when finally playback stops it can do such tasks. When I now again start playback before it's finished with such tasks (which can really take a minute) the playback just fails for all sorts of reasons. This in itself is related to the priority dedicated to playback and all starts to fail.

Why the mentioning of driver/DAC being the culprit to some extend ? because I never heard any problem you know mention, and as you know many even operate at 705.6. Notice though that nobody uses AI as well (which you might be doing) and so it can be about that as single reason already (if this is subject to your issue of course). I just gave the example ...

Charlie, nothing of this post should solve anything directly. But it hopefully gives you the insight of how to avoid the issue.

Last thing : CPU usage tells nothing; 1.186 should be used with Q3,4,5 at 1,1,1, and now look at the cpu usage.
Hiccups at once per 21 seconds tells all, because it will be the SFS size (make it twice as small and look again). Make it small enough and no issue might be there (so yes, now I am talking about the SFS being too *high*). All now suddenly is related to the performence of the (implied) Playback Drive ...

Peter

[charliemb]

Thanks very much Peter. 

This is a very high quality answer and also the most help I've gotten on this problem so far.

I agree with everything you wrote.  This is a steady data stream challenge.  I have no doubt that xxHE can provide the steadiest stream once we get the settings right.

No doubt there is a DAC aspect to this.  And the DAC maker has offered to make adjustments to "open the window."  I'm trying to avoid those changes because surely the settings are "as they are" for sonics.   I'd rather wait a little longer for playback to start and have the PC provide a steadier stream.

BTW,  for 384, I'm leaning toward custom and away from AI.  Meaning, all of this is occurring with custom or AP.

Another possibility is to allocate more kernel memory space as this may all be related to OS swapping, cleanup, and such.  (E.g., In some instances of alt-e alt-p I've heard the wrong track start playing.  That's probably not Engine3.exe putting out a bad pointer and so I look to the OS.)

Regarding the Device Buffer Size,  previous testing resulted in clicks at 1K, so I set it to 2048.   I will retest this.   (DAC maker claimed that the driver buffer size was 8K but there was never anything special about setting Q1=2 and Dev.Buff.Size=4096.   I will play with this too.

I'm also thinking XTweaks off,  at least until I solve this.

Thanks again,

Charlie

[PeterSt]

E.g., In some instances of alt-e alt-p I've heard the wrong track start playing.

I would ignore this for related issue; this can happen all the time. It is similar as alt-x during playback and the running time pointer is just at 0 (and often shows the wrong track selected).

Regards,
Peter

[charliemb]

Thanks again Peter.

After four straight nights of uninterrupted music, meaning no problems from xxHighEnd 1.186i, I must report what appears to be success. 

And for those who may experience a similar issue, here are the adjustments I made:
1. Enable "Always clear Proxy before Playback" and disable "Include Garbage Collect"
2. Get the buffer to 8K (*) by setting Device Buffer Size to 4K and setting Q1=2
3. Set Player priority to "Higher than normal" (was Realtime)
4. Set Thread priority to "Below normal" (was low)

* 8K was the size specified by the DAC manufacturer as the device driver's buffer size.  DAC is Wyred 4 Sound DAC2 with DSDse upgrade (384 KHz).

I'm not sure if any one of those four are critical at this point.  But certainly that combination appears to work well.

I tried many other things, including USB cables and a dedicated USB card with NEC/Renesas chipset as recommended here.  These did not seem critical.  Although I can say that a Pangea USB PC cable for $35 sounds better, hands down, than my previous cable.  So the Pangea is still installed.

One thing I can say that looks strange is that the xxHE executable folder is being written with track .wav files.  I've never noticed this before and it is as if I checked "copy to xx drive by standard" which is unchecked as recommended by Peter.

[PeterSt]

That is great Charlie.

The .WAVs you see in the XX folder are the decoded results of .FLAC etc. They always go there.
The "Copy to XX folder by standard" copies the WAVs to there to even though this is not necessary to play them from where they are (it's a SQ thing).

Bet regards,
Peter

[charliemb]

Thanks,  and...

Last thing : CPU usage tells nothing; 1.186 should be used with Q3,4,5 at 1,1,1, and now look at the cpu usage.

Also, with regard to this, when I try 1,1,1 the task manager does not update.  Normally I look at the graphic showing all 12 virtual cores to see what is happening and where.  But the entire task manager pane just stays as it was before I started playback.  After I it stop it eventually becomes live again and I can see the alt-x activity a little bit.  So this 1,1,1 is a powerful tool for controlling resources but I can't see what's going on.

[PeterSt]

You are right. But actually you'll know what I mean.
Should sound way better though ...

[charliemb]

Q3-5=1 1 1 @ clk=15ms sounded best of all last night.  But tonight I preferred my old setting of Q3-5=0 0 3 @ clk=5ms, which I arrived at independently of when and how you and others did.  Plus, with 0 0 3 the unattended background updates quickly, whereas with 1 1 1 it can take 30 sec to 2 minutes.  1 1 1 sounds cleaner and 0 0 3 gives a more open and richer sound over here.

So I  can only imagine that 1 1 1 is somehow resulting in even CPU usage, and even HIGH CPU usage, correct?

[PeterSt]

Quite correct (correct).