XXHighEnd - The Ultra HighEnd Audio Player
July 30, 2014, 05:00:04 am *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Dec. 31, 2012 : XXHighEnd + Phasure NOS1 DAC receive 6moons Blue Moon Award !
** "Lonely at the very top" **
Search current board structure only !!  
   Home   Help Search Login Register  
Pages: 1 2 3 4 5 6 7 [8] 9 10
 on: July 19, 2014, 08:37:06 pm 
Started by charliemb - Last post by 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).


 on: July 19, 2014, 08:08:23 pm 
Started by charliemb - Last post by charliemb
Thanks very much Peter.  thankyou

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,


 on: July 19, 2014, 02:19:17 pm 
Started by manisandher - Last post by christoffe
The AKG K-1000 headphones is one of the best money can buy, and the design is more a "near field monitor" (panels are rotatable/to tilt).

Maybe Mani is listening to his speakers in a near field position.

Otherwise headphones and speakers (with the influence of the listening room) are two different worlds.


 on: July 19, 2014, 11:55:36 am 
Started by PeterSt - Last post by PeterSt
Some will love this, some may not at all. Personally I think I do because what else would be left for tweaking ...

USB cables now matter.

Most of us know that the last larger "noise" subject in order was about the USB interface and how to tweak that for the better. This was not per sé about better ("SQ") quality USB cables, but the way the interface performs as a whole and how things are related to timing. Also, the very very last subject I recall was about the length of the cable of inherent same quality.

Never I saw a real relation myself between that and XXHighEnd settings, or in other words, I never saw anyone writing "with USB Interface tweak XYZ you better set dial A in XXHE to 0.7". So not.

Maybe it has been too much in between the lines, but I already had my doubts about Windows 8  vs. Windows 7 not making a difference anymore, but which I dedicated to the PC's being different for it over here. Btw this attitude did not change although I must say I did not spend mucht time on it anymore. What did change though is my attitude to the PC itself not making a difference, which in itself I now like to dedicate to USB again. Again ...

The above summarized : XXHighEnd hence software does not influence anymore, but that other thing in parallel, USB ... I think it still does. But it also does more than before now ...

This latter needs more experience than I can apply on my own. I mean, I was told a week or so back and only yesterday felt like having some serious time to try it myself. For me, and this one evening with one swap only, it would be too soon to really state it is true, but combined with what I was told - yes. And it doesn't even look to be marginal.
Fun for me anyway : the sound improved from using that other cable and accidentally this is the one supplied with the NOS1(a). Otherwise I have always been using a USB3 cable with converter (not the best they say, but I didn't pereceive a difference from it anyway).

What has changed is the again better resolution the NOS1a shows hence it is more easy to detect differences. So for me myself - I have been listening to the NOS1a for maybe 10 weeks by now, and the change of USB cable (just one random attempt) made me say "wow, so there's even more improvement around the corner !".

Yes, and this while it has always been such a nice gag that for the NOS1 the cables did not make a difference. So maybe I am a bit sad as well. Or not at all - still to decide. Happy

I promised myself to measure the performance of the USB interface because with the (ultra) fast analogue scope I am sure I can do/see a few things. When this is going to happen for real, don't ask me. But it should now be at a more "technical interface level", or IOW a 100 times more easy than when XXHighEnd would also be influencing in parallel.

There is one more thing of importance :
Because I generalized the both XXHighEnd and USB interface to being one and the same (maybe against all odds because as said I always have been thinking that both are not about the same influence), all NOS1's we receive have had reconnected their internal famous ground wire to the PSU screw. This has not been really thought over, but it looked more "back to basic and all good". By now I don't know that for sure, but I do know that my own wire never was reconneced, as well as that I still use the isolated Silverstone. All I want to say with this is that while people disconnected that wire in their NOS1 they may like to do that again in the NOS1a because this *is* 100% USB related.
Meanwhile we will keep on reconnecting them during the upgrade from NOS1 to NOS1a (to have things consistent for everybody).


Not many people will expect that now they can try different USB cables, just like I myself never made an attempt. It is thus also not said that at this moment with your NOS1a you have the best achievable sound (like in my own case as it seems).
At this moment I think that your best (or cheapest) option is to try different lengths. Thus not more expensive but just different lengths and otherwise just "other" hence what you have laying around.
It is a hunch that the shorther the better it could be. Only a hunch.

Happy tweaking !

 on: July 19, 2014, 10:52:15 am 
Started by manisandher - Last post by PeterSt
But I don't know... sometimes an oil painting is more gratifying than a photo...

Hi Mani,

I think you did not put your last two posts forward for a "discuss", but it just as well might be your intention. Anyway I feel that I should tell "back" something, but it is hard to come up with something useful. So just to let you know I'm there ...

FWIW ... Personally I would never take headphones for a reference; They are too different. The one element can perceivedly show for the better, the other never will be able to. As long as the latter does not express in distortion as such, the former will prevail and the remainder can be snowed under by it.
IOW, possibly you make yourself mad by wanting the same sound you perceive from the headphones, which just can not be.

Here's one why I never use headphones :
With headphones the music will be right in your head. You feel it nicely playing in the middle-top of your head or something and although the effect is something like being involved, the effect is also fake. I never like fake, or to be faked (influenced) by something which can not be real enough. So this is what I explicitly don't like either (and I know I am quite alone on this) :
When I'd be sitting in the sweetspot and close my eyes ... headphones effect. All sounds better right away but actually I have no reference. When I open my eyes, all sounds thus different and I can see how a plant already influences. Probably not physically (like in influencing the sound waves) but it contributes to reality. A glass of wine would do too and candle light would. And so this is not how I listen because it will be of no use that I tell you all how great the sound is, while it really is the nice wine + candle light doing it, while you like beer and are more of the Manchester United kind.
Try headphones with that plant and all should get confused. Only closing your eyes would let emerge a kind of consistent situation (no context because there plainly cant be any (no plant now *can* influence physically, right ?).

So far my attempt for contribution ...

 on: July 19, 2014, 10:05:34 am 
Started by charliemb - Last post by 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 ...


 on: July 18, 2014, 08:32:37 pm 
Started by xp9433 - Last post by PeterSt
To keep it clean :

Nothing tells me at this moment that the plane was shot ouf of the sky from the ground, no matter what I said in my previous post. One thing though : it would be quite complicated for someone on board to be on the wrong plane (the military plane for sure not coming from Amsterdam, though I did not sort that out). Regarding this notice the merit of the message of that tweet again.

 on: July 18, 2014, 08:24:58 pm 
Started by xp9433 - Last post by PeterSt
Well, then maybe Mr Roberts is wrong this time. And notice that I am all into conspiracy theories, so it is not that.

We are a bit more "on the news" than any country else I'd say. Or at least it's on an about continuous 24 hours now, so people really dig (and I maybe saw/heard two hours of it).

90 minutes after the news got known over here (which was about two hours after the happening), this was found :

Some separatist over there had twittered that XYZ Military plane was successfully shot out of the sky. Notice that an hour later this tweet had been removed again, because apparently some mistake was in order (no millitary plane at all).
This plane did fly right behind (or in front of) the passenger flight.

No separatist is able to man the equipment involved they say (the plane flew higher than 10Km and no normal fire can target anything that high). So this equipment has been stolen from the Russians or whomever (in the fights involved) and next the separatists themselves say "how could we have done it, because we don't even know how to use such equipment". But this is of course not the same man / group saying that.

So my personal thinking :
Ah, such equipment I can use too. Switch on with some buttons until a screen lits "identifying" air planes. But this latter, the identifying, is where things get tough. It needs possibly separate communication to really identify the individual plane, and *that* education lacked.
So pull the trigger.

Also notice that I think this was the 4th plane in a few weeks of time, and in no circumstance civils were in those planes. This time though it was full of them and there is no single reason why this would have been on purpose, especially taken into account that tweet which just was there.
So there is also no reason to think conspiracy when first other reasons are far more logical. And so I also think that Mr Roberts is quite fast on the trigger with such a subject where so many deaths are involved, not waiting for better outcome of first (hand) research. So, accusing a couple of government leaders and mention a couple of deaths as a side note ?


 on: July 18, 2014, 08:20:27 pm 
Started by charliemb - Last post by 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. 


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.

 on: July 18, 2014, 07:33:27 pm 
Started by xp9433 - Last post by Mamba315
As usual, Paul Craig Roberts has an educated guess on who's really behind this and what the motives are.  All of his articles are WELL worth reading IMO, and are free on his site:


Pages: 1 2 3 4 5 6 7 [8] 9 10
Powered by MySQL Powered by PHP Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Valid XHTML 1.0! Valid CSS!
Page created in 0.267 seconds with 15 queries.