Hey Johan,

Of course you can try what difference it makes (and whether sufficient) to

a. Shut off the Wallpaper;
b. Set the "Split files" at the minimum of 12MB.

Since you say that the Mem box already helps, the latter might be sufficient already. Why ?
With the Mem box nothing is preprocessed in Engine3 and all is done in real time. This is equal to a file to be preprocessed of 0MB. Thus, set that to 12, and you'd have at least less than your current 700MB setting (which in practice would be some 140MB for the 7 minute file). This is 12MB to process against 140MB and it just could make the difference.

Oh btw, I will keep on trying to be helpful, so please do not see my advise for a new motherboard as something to leave it behind me, and you stuck with it.
Also, may the Wallpaper do the job, I think I could make something that being treated with less priority.

Peter

I sent you a PM Eric.
Peter

Of course it is not !


Ok Johan, I have made a mistake in my previous analysis ...

Let's take the last X3 log file;

Note : The trackload is allowed to take 14 seconds. This normally allows for a complete CD to load easily (a good fast system will need 7 seconds for that).

At 13:21:49 (rounded) the first track is ready to play. It lasts 1:22. So, assuming playback of it starts immediately after this (and it should, especially for the first track) it will last until 13:21:40 + 1:22 = 13:23:02. Now, 14 seconds before it ends, the next track will start loading if present. This should be at  13:23:02 - 14 = 13:22:48. However, this happens at 13:23:03 which is 15 seconds too late.

The withgoing XX file shows that at 13:21:44 XXEngine3 acknowledges that it has started, which by itself is visible in the X3 file.

Back to the X3 file; this shows that 13:21:44 the Wallpaper commences to change, but, in your case this seems to take 2.5 seconds at least. Why at least ? because this is a parallel proces (ChangeWP) and XXEngine3 does not need to wait for it. However, since it takes 2.5 seconds (from 13:21:44.77 to 13:21:47.20) before XXEngine3 comes to the stage the music file is found it must be the conclusion that ChangeWP eats the CPU time the loading in XXEngine3 needs. But, the "loading" itself only starts after "music file found" and ahead of that it hardly does anything. It is fuzzing around with the .dat files a bit, similar to what you see 13:23:03.7680290 (but which doesn't show at the first track because the first track is treated differently).

In the XX file we can see that the second track starts to do something at 13:22:57, which does not comply to the 14 seconds XXEngine3 reserves, but which includes XXHighEnd to be fast or slow at her timing. But, XXEngine3 will start waiting for the new track from off 13:22:48, as calculated before.
The XX file shows that the track is there at 13:23:00.144, thus it took 3 seconds for XXHighEnd to ... fuzz around with .dat files again. There were no conversions, nothing.

At 13:23:00.192 XXEngine3 tells that it has found the info on the new track;
X3 shows that at 13:23:03.76 it starts doing something with it. This looks impossible to me. Remember, the first track lasts until 13:23:02. So it actually has finished playing already. At that stage (finished playing) it is looking for new track data each 20ms. The 13:23:00.192 shows that it did find the track data, but it lasts 3.5 seconds before it "wanted" to do something with it. Even at being idle (the 20ms loop) it takes over 1.5 seconds to start doing something.

Johan, you have a serious problem in your PC;
Your processor seems to have difficulties with multitasking, and switching tasks in general. Try get an Intel instead (if one fits in the socket).
Besides that, you have some serious problems with hdd data access. Although, it may derive from the same origine.
Also keep in mind the very strange problem you have with not having access to the data (.dat) files if I only treat them in that one particular way (which I luckily could avoid).
It looks like you are having additional problems with the writing time to the display, which somehow may be logic for the kind of special display (and probably interface + driver) you have.

I can imagine that other settings of Core Appointment help, and the best might be "No Appointment" as well as not setting the priorities ("Nothing") might help to some extend. But reboot after changing the settings to "nothing", because nothing is not explicit, and old settings may stick otherwise.

My best advise would be to get another motherboard for EUR 80 or so and with a processor like a core 2 duo E6600 this is doable I think. I may save your from lot of troubles.

Peter

No Leo, my fault at all times. I must investigate it, but it will be my task to prevent from these things.

Thanks,
Peter

The download is completely at the bottom of this page.

The following changes have been applied :

• As the title says : Changes of the Digital Volume now go without interruption of playback (Engine#3).
  Quite sophisticated, hopefully not too prone to bugs, but with memory playback 100% preserved this is now possible.
  Note that the change will (and can not) be applied immediately, but may take a second to come through.
  
  Works Attended and Unattended just the same.
  
  Currently this works the same for the Invert (Absolute Phase) toggle.
  
  Important issue : Currently, don't use this on the last track of (a selection of) the Playlist. Or otherwise Playback will commence somewhere in the middle of the previous track. Also think of what could happen when "Format Change" is set to Allowed, and that previous track has another format !!
  
  
• Along with the above comes an indicator at the top left of the screen, showing green when a change is pending. When the green light stops within two tenths of a second the change will be applied or have been applied.
  
  
• Similarly the Wallpaper will show a change of color in the area as indicated in below two screen shots. Note though that at a change of track this color changes just the same.
  
  
• At using the keyboard HotKeys the previous version (or two) could let start a track all over instead of continueing where it was. If all is right this has been solved now.
  
  
• The Wallpaper can now show the back of the CD (tray). This will be so when a Back.xxx exists in the same folder where the file for the cover was found and with the same extension. In this case the tracks of the album will not be shown explicitly as with the virtual cover.
  
  
• The Wallpaper will now show the Digital Volume as well as an Absolute Phase indicator (near the top in the middle of the open folded tray). At normal Phase "~" will be shown, whereas at Inverted phase an "I" will be shown.
  
  
• When the Clear button was clicked before, the timer cursor would reset to 0 only when sound was playing. Now this happens in all occasions.
  
  
• With Engine#1 and #2 an error could occur in ReorganizeProxy about a file being in use. Solved.
  
  
• After a new Install an error could occur indicating that a minimum value was not allowed to be 0. The previous version already tried to solve this, where it did not. Hopefully now it does.
  
  
• Last but not least, WiFi Remote;
  
  After you unzipped the download you will find a XXTCPSrv.exe in your current XX folder. If you run that, it will go to the taskbar tray and shows as a grayish XX icon. Rightclick on it, and the top option will show "Config". See the third screenshot below. Click that, and a form will show which allows you to indicate the Remote Configuration File to use.
  Note : At this moment the entered file will not be known any next time you start XXTCPSrv which is quite inconvenient. This will be better at a next version.
  The (applied) contents of the file will speak for itself, hopefully.
  When you wish to start capturing Remote Commands over WiFi, just click Start (again see the third screenshot below).
  At Exit, capturing Remote Commands will be stopped, and after that XXTCPSrv must be started again. You may create a desktop icon from the XXTCPSrv.exe in your XX folder (rightclick - Send to Desktop).
  
  Please keep in mind this is a first version of this and many enhancements will be possible, including more tasks to be remotely performed.
  
  Edit : Important : Currently the portnumber to use on the PC where XXTCPSrv will run is fixed (forgot to make it settable ); As long as this lasts, anyone needing the port number can send me a PM about it. Please don't ask further questions by PM, and when you have questions ask them on the forum instead.
  
  Edit 2 : The zip in this link solves that : WiFi Remote.
  
  

Hi Johan, I have been thinking ...

When you try this again (with the log files) Attended, I think I can see better what is hapening. That is, if it then too goes wrong. It may not, which also will tell me something.

To the ultimate I can give you a logging version of XXEngine3 I use for myself, but I can't do this right now because I don't have a consistently working version. Maybe at the end of today ...

Peter

Hey Johan,

Please help me (somehow) ...

From the X3 file you can see that at 22:49:54.6965640 the loading of the track starts, and at 22:50:04.1647080 it is ready to play (look between the two ----- lines). That is half of a second to prepare the 7:41 track no matter what preparations had to be done for it ... they were applied. This is Unattended playback ...

Now wat could be holding up after the last line in the X3 log file ? I really can't think of anything.

Right after the last ------ line all is in memory, and te only thng it takes after that is playing the previous track to the end and switch over to the other track. This happens within the notice of ONE sample.

At ripping, you didn't apply something like "insert space (of 2 seconds) in between tracks", did you ?

Maybe it is time to provide me with two of those subsequent tracks bothering you ? Pleasedo if possible. Never mind if it's FLACed.

Solved in 0.9x-4.

Note that I discovered along with it a ChangeWP error, hence the Wallpaper won''t work anymore for Engine #1 and #2. I will try to solve that too.

Hi Johan,

Although the graphs show everything should be within limits, somewhere they are not. But I can't think of where and how.
Could you please incur for the problem again, but now with logging switched on and post (or send) both the XX and X3 files concerned ?
In this case you MUST be able to hear the gap, or otherwise it is of no use.

Thanks once again ...
Peter

I still have it, but haven't used it for two months or so. But I will again, but then a good one ... (Intel).

Hi Bjorn,

I am not sure whether your last sentence was a question, or just the outlay of your final route to Walhalla. In the case it was a question :

I would not be sure about that without investigating / asking the supplier or test it. I mean, when you route an audio stream to SPDIF (which is what you would be doing with a DAC at the other end of the Firewire) it is not said at all that the internal DACs of the soundcard are operational at the same time. If they are, they are, but this is to be investigated.

Am I correct that there were no other questions ?

Peter

Aha ... thank you.

But does this happen at each occasion ?

And what happens with Unattended ?

Hi Johan,

No, I do not suggest that SQ will be better. It just may, and if so it will be about less dynamics (IOW you may have too much of it, which really happened at one of the very first versions (was not public)).

On the gapless ... I saw your CPU figure (doesn't look wrong), but I can only imagine that the CPU takes too long.
Can you post a graph of it (Performance -> Prestaties) which captures the playing over track boundaries and when you expect gapless while it is not ? Indeed switch "Copy to XX ..." on. I think that will make things very clear to me ...

Peter

Oops ... before when I looked at this I saw it was already in there, but in the mean time this bothers me just the same now and then.
What I see now, is that the resetting of the play position only happens when sound is playing ! So I guess that is the problem ...

Thanks !
Peter