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.

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

[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.

Hi Peter

No problem on the title change.

So, I'm still having the 1.186i issue and I will start a separate thread for that one and include the latest inforation because I now know that some of it turns out to be incorrect.

Hi Peter

This is similar to the issue reported by JohanZ in “ New filter: error message “ thread.
However, to the extent that this problem and JohanZ’s problem are the same, this confirms that it has nothing to do with the new filter (as suspected in that other thread) because this is a fresh 1.186a install and there is no new filter.

The problem is:
   1)  after I hit alt-e or alt-s while playing unattended, when I hit alt-p to play, Bill Gates pops up a window and says that xxEngine3.exe has stopped working and gives me the option to close it.  I select the option to close it.  And since I have no engine I hit alt-x to start all over;
   2) Once xxHighEnd comes back (I’ll save the long explanation and just say: ) the Kernel Streaming driver setting is lost and the WASAPI driver or the High Definition driver is erroneously selected in settings.  And so when I try to play I get, paraphrasing, “Product of Q1, xQ1, buffer size is too large …” message followed by several other error messages like “2, 32, 352500, …”,  and “could not…” and sometimes “Engine _ is for XP {or vista or whatever}”.

Now as best that I recall, bringing up xxHE from unattended while music is playing, then clicking on the UI stop button (not alt-s), this sometimes keeps the proper KS settings and it is possible to select a new album under [L], hit play, and it can work.   BUT sometimes not, as best I recall, sometimes not.

THIS IS RELATED TO BEHAVIOUR I WAS SEEING WITH 1.186i
What is interesting is that the reason I reverted to “a” was because I was seeing a problem with “i” as follows.  I figured “i” was beta-beta and I could not expect perfect behavior.   But it turns out “a” is worse for me.  But the good news is that supposedly stable “a” should be giving us a clue.  Do you see a similarity?

The problem with -->i<-- is:
1)  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.
2) Once xxHighEnd comes back, the DAC no longer synchs when I attempt playback at 352 or 384.  Hmmm.  Sometimes if I play a full track at 44.1 it is possible to play again at 352.  Else, a reboot solves this, but eventually, it would fail upon attempting to play, forcing me to eventually go to HQPlayer or JRiver which play almost perfectly at 352 or 384.  I was hoping that reverting  to 1.186a would allow me to use XX again for a while until the 352/384 filters come out….  But no, a similar problem occurs.

Nothing is ever wrong with any 186 version after a reboot and selecting  a CD and playing fully through to the end.   All tracks play perfectly.  Something with 186 goes awry after the first explicit stop, either by alt-e, alt-p, or by clicking the UI, where clicking the UI has better luck.

BTW, 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 to use 32 bit packets and increasing buffer size, 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.   And BTW,  0.9z-9b has no issues. 

I can help here by saying that I'm running the same PC as Peter (I think) and I don't see this problem with the custom filter version 1.186i (or g) and I am running Win7 64 bit.

As for the compilation albums, who knows.  That is curious.  Perhaps it is because tracks of the compilation are not all the same somehow, or put another way, in a compilation album with tracks from different mastering sources, there may be higher chances of running into one track that is problematic somehow,  either in the format of the .wav or .flac or whatever, or in the data contained (music).

Thanks.  And to revert from 186i to 186a do I need to overwrite just xxHighend.exe and xxEngine3.exe?   ...or also xx.ahk or whatever?

Two hopefully quick questions:

1) Is it best advised to reboot out of MinOS mode before I switch between 1.186x and 0.9z-9b?

2) Is it best advised to reboot out of MinOS mode before I switch between 1.186a and 1.186i ?

After a fresh reboot, I also tried to revert to 1.186a and am seeing the same "preset errors," over and over.  I seems like it never stops so I shut down and went to sleep.   I reverted by copying the "a" versions of xxHighEnd.exe  Engine3.exe and xx.ahk (maybe the last  one was not needed?) over the i versions to see if 186a solves a synchronization problem I'm seeing now at 352 and 384 after I hit alt-e or alt-s in unattended mode, followed by alt-p,  which almost always causes missed synchronization,  and also at random times after my initial playback session ends when I proceed with further playback.

Except in my case, I have no preset file that works with 186a because I never actually ran 186a.  I installed "a" and then I probably  immediately installed 186h to get to the custom filter, which was the reason for upgrading.   Possibly I played one track, or part of a track but I don't remember.

So for me, should I delete the entire 1.186a folder and start again with a new re-install of 1.186a?

Hi Peter

I've been quiet because I upgraded my DAC to 384,  meaning I was without music and the ability to further test these filters for about 10 days.

I've noticed that few responses have been given with respect to the experimental 705 filter.  I'm willing to try it but I need a version that runs at 384.   Which begs the question:  why not provide 384 versions of the two 705 filters?   

(That was my way of asking for a preferred 384/352.) 

I can say that 352 has changed things.   That is, taking redbook all the way to 352 using the 176 custom filter has now resulted in my preference for that filter over the new AI.  At 176 AI had much of what I needed and Custom 176 was a little short.  But at 352/384 custom 176 filter very seldom has that dry sound and can be very clean and not hinting at lacking any critical harmonics.

This means that your filtering strategy is working over here the higher up in frequency we go, finally (something I bet all NOS1 users already know).  Meaning,  perhaps less ringing is needed as we go up in F.   Certainly some is needed though, IMHO.

Sound impressions of new Custom and AI filters.

Firstly,  I should preface this  by saying that I'm running my Sabre32-chip OS DAC  (Wyred 4 Sound DAC2) with the PCM filter set to SLOW, which except for the sampling frequency +-20% is like having no filter at all almost everywhere.  Meaning: I'm relying on these XX filters almost entirely for the sound.   But also, running the DAC like this tells me much about the filters themselves.  And also, it is closer to an unfiltered NOS DAC which shall remain nameless.

The sound.  These filters sound fantastic.  So far I've only used the Custom 176 filter and AI using only one setting which is with the % pre-post ringing set to 17% (which I imagine is like 34% toward linear phase from 0), plus noise shaping dither.  To various extents, they bring to XX what was missing, which over here was an overly clean sound which sometimes sounded dry.  Not that I ever heard a problem.  It was more that I knew something was missing.  For example, I have some tracks by female vocalists and I know, because I've heard them before, that I should be melting in my listening chair.   But there was no melting.   Bit perfect would solve this but was too rough.  Once you hear the smoothness of AP it is hard to go back to bit perfect.

So I found myself using AP for rock, instrumentals, and male vocalists.   But for female vocalists, flutes, violins, violas and such, I had to turn to AI or no filter, or HQPlayer, and for all of those the melting happened / happens.   But all of these alternatives had their down sides as well.  For HQPlayer and to a less extent the old AI, the soundstage and imaging was nothing like AP.  Big losses there.

Then came these new filters in 186a and i.  We are already well past the melting.  The harmonic richness, which is what was missing, along with a correctness are now extremely satisfying for both Custom and the new AI.   And as expected, to varying degrees.

Custom still sounds a little like AP, and now only rarely exhibits this "something is missing" harmonically situation, but retains the amazing soundstage of AP.   And I'm glad to hear Boleary write that it exceeds AP.   I've not noticed that it exceeds but I will listen for that.  Certainly AP continues to be amazing in this regard and Custom is close, at least. 

The new AI is also a bit of a miracle.  Certainly is sounds better than any HQPlayer filter right now.  That's amazing when you consider the refinement of HQPlayer's filters.   But like HQPlayer, the new AI (@17%) looses a lot on the soundstage and imaging..   But what it looses in imaging it compensates in harmonic richness.     Where Custom can sometime sound a little lacking harmonically,  the new AI never lacks, and perhaps gives a little too much (GOOD for an alternative).  Have a dry sounding CD?   No problem:  just throw the new AI 17% at it.   Also amazingly,  the new AI never trips.  It never stumbles,  and everything seems to sound great.  Oh, except for the lack of soundstage in comparison to the amazing AP and Custom.

Hint hint...  I'd love to see something Custom that was asymmetrical in between this current custom 176 and the new AI set to 17%, more or less.  And okay,  if too much soundstage is lost,  then closer to current custom 176. 

Very very happy to have these filter choices.  Thank you Peter.  You are either very lucky or you are a genius.  It's always hard to tell between those two.

Indeed, it does, well, sort of.  By that I mean that the first time I tried a wav file, it did not work. (huh?)  So I stopped the loading, clicked on [c], killed engine3,   and tried it again.  Then it worked!   Well, again sort of.   By that I mean that for that particular album, only 7 out of 12 cores (hyperthreaded) lit up.  Huh?   why only 7.

So I found the few other wav albums that I have and they had no problems lighting up all 12 cores.   What's up with that?

And playback drive, or not, made no difference.

So, okay, new datapoints.

(been busy and I could swear that I have already posted about this but I don't see it.   maybe it was just a dream.)

specifying a playback Drive did not solve the problem.

Aiff 16 bit 44 kilohertz did not multitask...  only one track at a time.

Okay,  then I will check tonight by forcing to playback drive or forcing the xx folder and see.  But since most of my collection of CDs is Aiff, and Aiff must get copied, I don't see why that would work.  But as you said, this I/O stuff and multitasking is complex.  Anything could be.

and so Aiff  gets copied just like Flac no matter what?

and it is only wave that sits and stays where it is?