XXHighEnd - The Ultra HighEnd Audio Player
July 31, 2014, 07:24: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 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:


 on: July 18, 2014, 06:47:38 pm 
Started by charliemb - Last post by PeterSt
Ok, thank you Charlie.

 on: July 18, 2014, 06:33:54 pm 
Started by charliemb - Last post by charliemb
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.

 on: July 18, 2014, 04:54:47 pm 
Started by xp9433 - Last post by juanpmar
That innocent people going about their business become collateral damage in a political game played in another country.
Commiserations to all who may have a friend or family hurt by this traffic shooting down of the Malaysian aircraft. Especially all those affected in the Netherlands.

I feel sorry for all those innocent victims in the attack on the plane. Also sorry for so many civilians killed, including women and children, in the present Israeli-Palestinian conflict. Meanwhile our politicians in Europe look away. It's really a shame.


 on: July 18, 2014, 01:16:30 pm 
Started by charliemb - Last post by PeterSt
Hi Charlie,

Maybe I must apologize for the long explanation you had to make, but this is a known problem for 1.186(a). However it is always announced differently and for that reason I changed the title somewhat so now a next one can find the problem more easily.

So there's a bug in 1.a86(a) which can select (not always) the first audio device in the list. And if this is not the one you are using, things go wrong of course and all you write about it is just dedicated to that. So the explanation of it all is now just easy.
If all is right this was solved from of 1.186-e, but not sure because not really tested. Why ?

The "best setup" so to speak should already have switched off all you don't use (which is thus what I do). This means that in Minimized OS (Normal OS does not matter because not used anyway if all is right) the one and only audio device you are using should be active in the first place.
And then this bug can not express (obviously, I hope).

What you generally do is shut off all in Normal OS for WDM devices and if that leaves Kernel Streaming devices in MinOS you don't use, well, deactivate those too (Device Manager).

Hope this helps.

 on: July 18, 2014, 11:53:20 am 
Started by KnB - Last post by Tore
Kjell, you are lucky having a wife with some of the same interest. I'm on holiday in Croatia, reading this forum every day. Yesterday my wife said: aren't you to old for that??  unhappy.     Tore

 on: July 18, 2014, 08:07:34 am 
Started by xp9433 - Last post by xp9433
That innocent people going about their business become collateral damage in a political game played in another country.
Commiserations to all who may have a friend or family hurt by this traffic shooting down of the Malaysian aircraft. Especially all those affected in the Netherlands.

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.26 seconds with 15 queries.