XXHighEnd

All,

Since the new memory management as per 0.9w-5 I think we need some (new) guidelines on how to play the sometimes huge hires files.
I took the most extreme for testing, which is this situation :

1. a 24/192000 DAC;
2. a 3 minute DXD (24/352800) file from 2L, occupying 387MB;
3. in the Playlist followed by a another DXD from 2L, 9 minutes 1.2GB.

Nr. 1 is rather important, because it implies downconversion to 24/176400 where Anti Aliasing needs to be applied. This is very time consuming, and may take a minute for the track mentioned under nr. 3.

Because the AA conversion takes such a long time, Attended Playback is impossible, or you'd end up with a huge gap in between the two tracks. Besides that, because of technical reasons Attended Playback will workout wongly at synchronizing between XXHighEnd (doing the AA conversion) and XXEngine3 (waiting for a limited time only). Because of unanticipated conflicts the lot will run out of memory.
Theoretically this is solveable which will *not* happen, because I personally don't see the reason of wanting to wait during the huge gap mentioned, while Attendedly playing is not the best for SQ anyway.

For AA converted files (which happens for DXD and a not suitable DAC) Unattended Playback is a requirement.

Kind of important : When you really want to play two subsequent DXD files with a 24/192000 DAC (i.e. no 24/352800 DAC), you have to wait for 0.9w-6 because of a bug found.

Then, you really need to put limits on the memory loaded portions;
I have 2 GB of physical memory, which in my system comes down to somewhere 1.3GB useable memory including the OS, for certain processes with the combination of XXHighEnd and XXEngine3. It is out of my control when the coincidence happens of being able to use the 1.3GB only (this is about virtual memory which is within physical memory, hence which is unrelated to the swap file);
When you set "Split file at size" (Settings Area) at 100MB, I am confident all goes well for those with 2GB of physical memory. Thus, this includes playback of two subsequent DXD files (be see above remark about 0.9w-6 for DXD and a 24/192000 DAC).

When you have more than 2GB of physical memory and don't apply AA (checkbox at the left in the general area), and where XXHighEnd doesn't apply it for you (like with downconversion from 352800 to 176400), YMMV. You will be able to set the limit on the file size at 400MB at least (I mean, that works for 2GB), and whether you'd even want to set it higher is up to you. However, when you receive a "XXEngine3 stopped working" with an exception code of e0434f4d you can be sure you ran out of specific memory at some stage. In that case, lower the limit and try again.

All 'n all there is not much reason to set the limit higher than 100MB, although at this moment I must honestly say that any lower amount than necessary makes you "vulnerable" to bugs/anomalies dealing with the split files. The one thing I know of myself is that a part of a file may be skipped (at least that is what I think I hear sometimes -> this goes without clicks whatsoever, so it may go unnoticeable), and it is sure *not* related to the anomaly of the end of a track exposing it's beginning for a fraction of a second (as mentioned in the Release Notes). I said "at this moment" because obviously this is something to solve.

Lastly, I want to emphasize that systems with large amounts of memory (like 64 bit systems with more than 4GB) will not benefit from that as expected;
The real limit for any process is 2GB, which means that relative to my own 2GB case (see above) :

a. there will be no coincidental limit at 1.3GB;
b. the memory the OS needs does not count for the limit.

Relative to my case this would come down to :
- 700MB more available because of a. above;
- some 500 MB more availabe because of b. above.

The latter certainly does not say that your music files can be 1200MB larger now, because every file is expanded in memory quite a few times (starting with a 24 bit file being expanded to 32 bits anyway; this more than doubles the size. This ends with two tracks needed to be in memory at some points in time because of the necessity for gapless).
In any case you should not think in "music files" but in portions of it, as implied by the "Split file at size" parameter.

Peter

No, this is not true. Only if you want compatibility with 32 bit.
If you make a 64 bit native executable you can go over 2gb per process limit.

Which is the case.
And even then that is not completely true, because VS2008, besides all, has the option to compile for more than 2GB per process.

All 'n all things are kind of misty (at least for me), because *not* being compatible with 32 bits sure does not allow 64 bits to run. That fooled me for almost a year ...

So now you know why I rather don't bother about that 2GB option. Sorry ...