XXHighEnd - The Ultra HighEnd Audio Player
November 23, 2024, 09:43:45 am *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: August 6, 2017 : Phasure Webshop open ! Go to the Shop
Search current board structure only !!  
   Home   Help Search Login Register  
Pages: [1]
  Print  
Author Topic: XXHighEnd Model 0.9v-6 (solves silent playback)  (Read 7630 times)
0 Members and 0 Guests are viewing this topic.
PeterSt
Administrator
High Grade Audiophile
*****
Offline Offline

Posts: 16854



View Profile Email
« on: September 06, 2008, 06:05:12 pm »

at last ... (see Wav stops playing)

Thanks to the great help of Calibrator / Russ who seems to have a PC prone to these problems and his encouragement to build in detailed log facilities which he then wanted to run over his system, the following problems were solved :

First of all the silent playback of course;

At Attended Playback at completely random moments a track would play "silent". The cursor from XXHighEnd just running, but no sound during one track. After that the next track produced sound again, and after a few tracks it could happen again.
Somehow this seemed to occur right after a reboot only, and sure not with everyone ...
This was not related to the sound device acting weird, not was it Vista doing it ... it was a stupid programming mistake related to the time one process (in XXHighEnd) needed to complete a "situation" and the other process (in XXEngine3) running in parallel not taking into account that XXHighEnd possibly only started the situation, instead of looking at the finishing of it. So, XXEngine3 fell in the middle of that process, all coming down to partially lacking the data to perform the job right. This included the data for the Wallpaper process (which was proven a stage earlier already without knowing the cause) and which so far was solved by means of a backdoor solution (not treating the cause).

The reason why not everybody encountered the problem layed in the intrinsic "speed" of the PC, that, when fast enough, was able to finish the one process faster, hence making the chance the other process falling in the middle of it, smaller. And that's why a laptop was more prone to it ...
Also the phenomenon of it happening right after a reboot is explained now, because Vista will be organizing things for quite some times after a boot. In the end though, it was proven that it kept on happening, but in a fasion less likely to notice;

Beforementioned "partially lacking the data to perform the job right" could come down to not knowing the tracklength (that being perceived as 0 then) up to sending data to the DAC with "default speed", or IOW 44100. This by itself could cause the "slomotion" people encountered, but, which happens by the coincidence of the DAC being set to a fixed speed (if not, the speed will be controlled by XXEngine3, and you probably wouldn't notice, again depending on *other* data received wrongly, like a set Double which was read as "not double". All coincidences coincidences.

The effect on real crashes within XXEngine3 are unknown, but most likely they did not happen, although again this could be dependend on environmental settings like the example of the fixed DAC speed.

When this was solved, the log files showed another anomaly : one track could load more than once, which again was caused by careless programming, but encouraged by the priority settings, the thread dealing with the trackload (set to the lowest priority) not being able to tell in time that it was running already within the time a next check was done for whether it was allowed to start. Yep, these things happen when one problem is solved (think back of the "ticks" during trackload that could happen for some) and things are in fact too complicated to change once they are running well.
Whether this by itself created "crashes" ... maybe. It can not be overseen what is causing what when a track is loaded twice in parallel, in the mean time consuming twice the memory, or just not but then overwriting its own memory while in the mean time it already started playing. Anyway it would be a good cause for tracks abrubtedly stopping towards their end, because one of those double (or even triple, as seen) tracks would - or anyway could overwrite the playing track.

To conclude this : please report if you find ANY anomalies during playback. They should all be solved now, or they weren't reported (and noticed) in the first place.

Further changes :

  • There's a TemporaryData folder now under your XX folder. It is meant to contain various temporary files which otherwise clogs up your XX folder. Over time some files types will move over to there.
  • A first one are the log files mentioned. They are available to you as well, and in the Settings Area a new checkbox "Log Activities" can be ticked in order to activate logging. A few notes :

    • The log files are meant to be helpful with playback problems / anomalies. With problems they can be sent when asked for (please don't just post them, because they can be long).
    • Per "session" a log file will be created, and it consists of date and time for your conveniency.
    • XXHighEnd and XXEngine3 are different instances, and each have their "sessions". With XXHighEnd a session emerges each time it is started, and for XXEngine3 this is the same. When all is normal, for XEngine3 this happens one time per "playback session", hence per pressing Play. Note though, when things are not right, this can happen more times under the hood. In any case, watch the file times when you're explicitly reporting, and send (again, when asked for) all the files that fall in the range of your trials (and not only the last 2).
    • XXHighEnd log files start with XX, and XXEngine3 log files start with X3.
    • The Log Activities" checkbox will remember your settings over sessions, but it will not at a new version of XXHighEnd. It will be reset to Off (unticked) then.

  • Somewhere in one of the latest versions an error slipped in dealing with the "Chk" checkbox (bottom of the Library Area) and it wasn't quite useable anymore. This has been solved.

  • Together with the above, the "Grp" checkbox has been removed. It interfered with things, was rather useless, and it never worked as intended anyway.

  • When (by accident) an individual album was asked for by means of the bottom "..." button in the Library Area (meant for music root folders) errors occurred at showing the album. This has been solved.


Btw, don't be surprised if there's a new version uploaded in no time, because the logfiles are running here constantly now, and things may come from it.

Edit : For now, do not switch on logging. It will cause anomalies by itself ! This will be solved ASAP.

* XXHighEnd-09-v6.zip (3481.65 KB - downloaded 647 times.)
« Last Edit: September 07, 2008, 08:27:07 pm by PeterSt » Logged

For the Stealth III LPS PC :
W10-14393.0 - July 17, 2021 (2.11)
XXHighEnd Mach III Stealth LPS PC -> Xeon Scalable 14/28 core with Hyperthreading On (set to 14/28 cores in BIOS and set to 10/20 cores via Boot Menu) @~660MHz, 48GB, Windows 10 Pro 64 bit build 14393.0 from RAM, music on LAN / Engine#4 Adaptive Mode / Q1/-/3/4/5 = 14/-/0/0/*1*/ Q1Factor = *4* / Dev.Buffer = 4096 / ClockRes = *10ms* / Memory = Straight Contiguous / Include Garbage Collect / SFS = *10.13*  (max 10.13) / not Invert / Phase Alignment Off / Playerprio = Low / ThreadPrio = Realtime / Scheme = Core 3-5 / Not Switch Processors during Playback = Off/ Playback Drive none (see OS from RAM) / UnAttended (Just Start) / Always Copy to XX Drive (see OS from RAM) / Stop Desktop, Remaining, WASAPI and W10 services / Use Remote Desktop / Keep LAN - Not Persist / WallPaper On / OSD Off (!) / Running Time Off / Minimize OS / XTweaks : Balanced Load = *62* / Nervous Rate = *1* / Cool when Idle = n.a / Provide Stable Power = 1 / Utilize Cores always = 1 / Time Performance Index = Optimal / Time Stability = Stable / Custom Filtering *Low* (16x) / Always Clear Proxy before Playback = On -> USB3 from MoBo -> Lush^3
A: W-Y-R-G, B: *W-G* USB 1m00 -> Phisolator 24/768 Phasure NOS1a/G3 75B (BNC Out) async USB DAC, Driver v1.0.4b (16ms) -> B'ASS Current Amplifier -> Blaxius*^2.5* A:B-G, B:B-G Interlink -> Orelo MKII Active Open Baffle Horn Speakers. ET^2 Ethernet from Mach III to Music Server PC (RDC Control).
Removed Switching Supplies from everywhere (also from the PC).

For a general PC :
W10-10586.0 - May 2016 (2.05+)
*XXHighEnd PC -> I7 3930k with Hyperthreading On (12 cores)* @~500MHz, 16GB, Windows 10 Pro 64 bit build 10586.0 from RAM, music on LAN / Engine#4 Adaptive Mode / Q1/-/3/4/5 = 14/-/1/1/1 / Q1Factor = 1 / Dev.Buffer = 4096 / ClockRes = 1ms / Memory = Straight Contiguous / Include Garbage Collect / SFS = 0.10  (max 60) / not Invert / Phase Alignment Off / Playerprio = Low / ThreadPrio = Realtime / Scheme = Core 3-5 / Not Switch Processors during Playback = Off/ Playback Drive none (see OS from RAM) / UnAttended (Just Start) / Always Copy to XX Drive (see OS from RAM) / All Services Off / Keep LAN - Not Persist / WallPaper On / OSD On / Running Time Off / Minimize OS / XTweaks : Balanced Load = *43* / Nervous Rate = 1 / Cool when Idle = 1 / Provide Stable Power = 1 / Utilize Cores always = 1 / Time Performance Index = *Optimal* / Time Stability = *Stable* / Custom Filter *Low* 705600 / -> USB3 *from MoBo* -> Clairixa USB 15cm -> Intona Isolator -> Clairixa USB 1m80 -> 24/768 Phasure NOS1a 75B (BNC Out) async USB DAC, Driver v1.0.4b (4ms) -> Blaxius BNC interlink *-> B'ASS Current Amplifier /w Level4 -> Blaxius Interlink* -> Orelo MKII Active Open Baffle Horn Speakers.
Removed Switching Supplies from everywhere.

Global Moderator
Pages: [1]
  Print  
 
Jump to:  

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.145 seconds with 19 queries.