Shut off Virtual Memory

[astacus21]

Also a good idea for those who have enough memory is to disable the virtual memory.

Windows have a built in function that stores some data to c:\pagefile.sys (hidden file) and load them to memory, as soon as you run the program that those data belongs.
You can disable this from my computer (right click)> properties> advanced system settings > advanced tab.
Here in the performance area click settings and in the advanced tab you can find the virtual memory.

Click change and set it to no paging file.

[PeterSt]

Also a good idea for those who have enough memory is to disable the virtual memory.

I don't think this is true for Vista;
First of all, this just CANNOT be shut off, no matter you think you did. The OS will just keep on doing it for herself, which you can see in TaskManager. However, if you can prove (!) that for your system this can actually work, then yes.

Secondly, you will receive unexpected errrors (hence errors which otherwise don't appear), especially when you indeed are able to really shut it down (see above).
Also, please note that at certain settings and track lengths you just *will* run out of internal memory, or can't control (= expect how much) that decently, which is subject to the way XX works.

All 'n all it is certainly *not* my advice to shut down virtual memory. Otoh, anyone who feels comfortable with that, including what he can expect hence interpret the errors from it ... go ahead.

[astacus21]

Hi peter

The virtual memory of windows (vista,xp etc..) is a mix of physical memory (paged physical memory) and hard disk space
(pagefile.sys).
With the above procedure you disable the part of virtual memory, that page data to the disk. After this you can also delete pagefile.sys from your disk because it is not in use.

You cant disable the entire virtual memory, it is not allowed by the OS.
I'm working with the above setting for almost 2 years and until now i haven't saw any error on screen.
My physical ram is 4gb, but i have also try with 2gb and i get the same results.
Some programs like adobe audition can show a warning that virtual memory is disabled, but you don't have to bother about it.
This procedure cannot create Blue screen or something bad to your os.

[PeterSt]

With the above procedure you disable the part of virtual memory, that page data to the disk

You cant disable the entire virtual memory, it is not allowed by the OS.

I sure don't want to catch you on wording , but you seem to think the swapping is going somewhere else (hence not to disk) ?

My physical ram is 4gb, but i have also try with 2gb and i get the same results.

Why should you try 2GB ? the 4GB is much better of course (and note you can address that in W2008), but there's a calculation somewhere in here that it really is not (it was 9GB I think) when you only play the high samplerate and high bitrate files at the best quality. But watch out : this is not related to the swapfile thing at all, because with or without, XX will die when too much memory is needed. It just can't use the swapfile. However, other processes will need the memory at the same time XX eats it (almost), and that is where you'll get the unexpected errors.

But as said, when you are comfortable with the settings as you explained, nothing stops you. I just don't want to explain the obvious to those who have the errors.


Just for your reference : Re: Track length (remember, unrelated to the virtual memory, but indicating that your 4GB sure isn't enough some times ).

[PeterSt]

PS: Another thing is, that the page file really isn't used when all of the above is applied;
If you'd stroll through this topic : 0.9u-12 --> Hiccups and Clicks, you can derive from there that it sure was before (and I bet this was about the prefetching idiocy). Especially see this post from that topic.

The fact that the page file isn't used anymore can easily be checked with the Source Control program. During playback with XXHighEnd that is.

[astacus21]

For sure when we have to deal with big files then it is not recommended, because obviously it will cause xxengine to close BUT
when we use the regular 44.1/16 wav files, a 1,4 GB memory is enough for about 2 hours playback.

...swapping is going somewhere else (hence not to disk) ?

I don't mean that the swap file goes somewhere else, i think you haven't understand what i'm trying to say.

The swap file is not exactly the same thing with virtual memory. It is just a part of VM.

Virtual memory is a memory space for the os, that it constist of a space in physical memory (the size is controlled by the kernel of os) and
the swap file, a space on the hard disk. By disabling the swap file, you just allow system to page memory to the physical memory only.

When a program needs this data from the page table, a chip insude cpu the mmu (memory managment unit) "sends" a request for this data to move from the vm, to the physical one. So if this data is allready to the physical memory part of vm (if you disable swap file this happens all the time) , then the os just translate those virtual addresses to physical memory addresses. This translation is much faster with swap disabled.

I know all this brings headache, but just try it and if you don't like it, is easy to set it back.

[PeterSt]

when we use the regular 44.1/16 wav files, a 1,4 GB memory is enough for about 2 hours playback.

I am sorry, but you really should dig up the posts that present the calculation to you.
For your two hours this would be 4.2GB plus the, say, 600 MB the OS (Vista) needs.

About the other stuff, you might call "not physical memory" virtual memory not being on the hdd, but unless it's on the CPU itself I wouldn't know where it is. Of course, you say it is in physical memory itself, but the only conclusion I draw from that when it is true, is that this is stupid dealing with memory (management). Just a waste. That is, I wouldn't know (nor design it) why to copy a part of memory to another part of memory, sitting there and waiting for when it's asked for. As said, unless it's on the CPU, although that's really the other way around (because that's fast memory (which we tend to call a cache)).




PS: About the 2GB limit and what happens then, I tend to believe. There is no way though that I would call that virtual memory.

[astacus21]

OK peter please delete the posts,are unrelated to the subject. But i  still believe that you haven't understand...
Please read carefully. It 's no so difficult anyway..

[PeterSt]

But i  still believe that you haven't understand...

That is true for sure !
I will dive into it seriously. Thanks.

[PeterSt]

Ok, I think (!) what you refer to is mapped memory address space. Thus :

IMHO there is no such thing as virtual memory outside of the paging file, and what remains is physical memory that can't be addressed in one 32bit address space. This is the "mapping" onto other address spaces. With 64bit things are different, but it still depends on drivers and mobo's how to deal with that.
Another thing, but in the same area, is how the memory is appointed for 32bit systems (for 64 bit this is no problem). I mean, when you have e.g. 2 GB of memory, only with the best setup (again drivers/mobo) that 2GB can be available to you. Take my own system, which has 2GB but only 1.35GB is available to me (and that 1.35GB includes the OS). Now the hard part : my "virtual memory" (excl. page file) is 1.94GB. Again IMHO the only thing what happens here is that drivers etc. are not able to appoint the full memory of 1.94GB, and the part outside of the 1.35GB is addressed via memory mapping.

Lastly, there's also the mapped area for driver space, and this is the amount that is calculated from the total amount of physical memory minus the total amount of virtual memory. In my case this is 2048 - 1940 = 108MB.

Here's all in a row :

Total amount of Physical memory : 2048 MB
Available Physical memory : 1350 MB
Total Virtual memory : 1940 MB
Available Virtual memory : 1280 MB
Space for swap file : 0MB.

So if I may, yes, outside the swap file there's virtual memory, and this is more than the officially available physical memory. But this is caused by, say, flawing drivers or a mobo which can't cope.
Note that this is similar (but more commonly known) to installing 4GB in a Vista consumer 32 bit (OS) machine, while only 3.1GB of it is available. In a 64 bit (OS) machine, the full 4GB will be available, but there things are (seem to me) a bit upside down : that may show 4.5GB, the 500MB is related to driver space again, but something is here really "virtual" and it is not there (something with dead space -> nog used anymore, but it still can be obtained, blahblah).


Now, to finish it off a bit for this post (and my side ), there's the swap file hence paging (please check this yourself with Taskmanager - Performance) (btw. this is 32bit Vista);

When I allocate a paging file of 2GB, "paging" is allocated of 4GB. Don't ask me where the additional 2GB come from and go to;
When I do not allocate a paging file, "paging" is allocated of 2GB.

In either case the additional paging space (hence the space I don't ask for), is almost equal to my total amount of Virtual memory, namely 1981MB (Virtual memory is 1940 MB in my case, see above).
What I have seen (referring to the topic I referred to earlier), is that the space consumed in that additional paging area is equal to what I stuff into memory itself. I explained that (just my own thoughts) as : "this is how Vista works, and when it has to swap out memory, it's already done ... aint that smart". The priority at doing this is obviously low (the stuffing of the real memory goes first), but it causes additional IO anyway.

... and now I am going to give you right ... Just readon on ...

What is IN USE by that paging mechanism, is the amount of (shown) physical memory plus the amount of driver space (that is, it shows 100 MB more than used physical memory, which is nearly equal to my 2048 - 1940 v.m.).

Then, interestingly enough, the space consumed by that paging area (the one we didn't appoint) is that when I load 100 MB additionally into physical memory, that space grows by 200MB.

So how does it work ?

The line "Page file" (see picture below) shows the total amount of virtual memory. In my case the page file has been shut off, so you see (the right figure) my total amount of Virtual memory (or very close to that) and which is the available physical memory plus the mapped address space.
The left figure - which shows the total amount being in the "page file", actuall is the total amount of physical memory I use. This is the shown amount in green (not shown in the picture below) plus ... the amount used in the mapped address space which in fact adds to virtual memory.

The above can be desribed much more easy : The amount of physical memory which can't be addressed on one go by your system just *can* be used as if it were a real page file on disk. And yes, as you already said, copying from there goes must faster.
But also : Like when the normal paging file is active, EVERYTING is copied to that area, while Vista is so smart to do that in advance in case I need it. One small downside : When that space is full, the program needing it dies.

And the latter is the phenomenon I talk about (also in that other topic) : I cannot control what's kept in there and what not, and coincidental "collisions" of really needed space with the OS just adding to that additional virtual area, let grow my system out of memory. Mind you, this is not true at all, because this is not swapped out data, but prefetch data (hence is copied there in case it needs to swap out from the real available memory area).

The above can easily watched, by knowing a bit what (e.g. XX) really needs, looking at the green figures witch match my idea about it, that showing e.g. 1000MB, while in the mean time the Page File number (left figure) grows to over 1500MB. The calculation to this is rather consistent : just look how much memory is needed (green figure) when no user programs are loaded.Say this is 500MB. The Swap file in use will be 0MB here. Now, when you load 500MB of user programs, the green figure shows 1000MB and the Swap file will show 1500MB. Load another 250MB and the Swap file (remember, this is just physical memory) wants to have 2000MB which is not there. It is here when things get stressed. As a not unimportant side note counts that when my user memory decreases, the Swap file decreases as well. This is logic, because it cannot be so that I would need its contents anymore.

So, in that other topic I proved that things go stressed within Vista when that Paging amount reaches its limit, and it must give priority to free it; it stalls the other processes (briefly), including sound.
Besides this we might wonder what happens when the user memory in use needs to swap out; remember, normally the OS can depend on the copy already being in Virtual memory, but not now. Now it has to make the copy in advance, and I dare to put some horses on it even can't.

It is nice that Vista can make this copy in additional Virtual (non hdd) memory for me, as a catch to my system not being able to have the physical memory fully available in the first place. But you tell me : what if my available physical memory would have been not 1350MB but 1700MB. There would only be some 300MB left for the additional Virtual memory, and things get stressed all the time. Keep in mind : this is not memory that contains swapped out user space ... this is a prefetched copy of it. If the prefetched copy gets swapped out because the area is full and cannot contain the full user memory, the user memory can't get fuller than in my case 1350MB, unless the part that needs swapping out at that moment, coincidentally is in the copy in the additional virtual memory.

I think I said in that other topic : this s*cks all over. Say, out of decent control.
I hope you can agree with me that this is nothing for a normal user to understands, who just *will* receive out of memory errors, and who obeyed my calculation of how much memory XXHighEnd uses and when. This user bought 2GB of internal memory, and doesn't even know that he has 1.3GB available really, which only in the very coindicental best circumstances can grow to around 1.9GB.

Add to this that XXHighEnd runs under Managed Code (which dot-net is), and that there's really no control of when what memory is freed (the OS "manages" this for you). With stupid tricks you can force some things, but not all, or they are to vague to control really.

If you disagree ir have other opinions, I'd be happy to hear them.
Peter

[astacus21]

Peter it's a little bit difficult to me to explain, cause english is not my native language but i 'll try.

It is nice that you make expiriments with memory, as your program, use it in a way that performance is very critical.
It 's impossible to me to answer to the above comments, because we 'll get lost in details.
You can't just look in the task manager properties, to see what the memory management of windows have done with memory, because you see just numbers, but you don't know from where (which application) this data comes.

It is more easy for me to explain, how the os acts, when an application requires memory from the system.

All this conversation is important, if we use a 32 bit os (it doens't matter which one). At 64bit we don't have remarkable limitations (we have but, the limitations come from hardware).

Let' s take the following example, that we have a system with 32 bit processor and 4gb of physical memory. I use this example, cause it contains all the others circumstances like 2gb etc...

A 32-bit processor uses 32 bits, to refer to the location of each byte of memory. This means 2^32, about 4.2 billion unique locations. Let's say 4 GB. Those are all the possible addresses of memory, that the cpu can use. So above this number the cpu just can't see those locations and can't use them.

Let's go now to the OS side, in the above example.
It is built in a way, that every single application that request memory, has it's own VIRTUAL 3gb memory space.
This means, that every application acts like there is ALWAYS* 3 gb of (VM) memory to occupy, independently from the fact that for sure this space doesn't exist in physical memory. So this application starts to PAGE it's data, in a continious virtual space, until it get's all the data to that space.

*The only limitation to this come from the OS, which have the "central'' management of memory and can stop this procedure, (paging) if the application allocates so much space. OS manages all applications paging procedure, in a way that the available PHYSICAL memory & the SWAP file doesn't run out of space.

This can happen, when the os prefetching the most used programms OR when an application requires much space in physical memory like xxengine process.

The 4 gb of our example are devided by the os, to 2gb kernel mode space (os kernel, bios, shadow memory, agp aperure size, etc...) and 2 gb for ALL applications space. (this can be changed with some  tricks to 1/3).

As i said to another post this virtual memory is a mix of space in physical memory and hard disk. If an application requests the vm data,
then a procedure take place and this addresses are translated to physical memory addresses, so that the application CAN USE them.
While this data are not translated into physical address space, only OS knows about them and no application can use them.
So for this translation if we have the swap file disabled, this operation takes much shorter because the hard disk doesn't participate.
This is the benefit.

So if a process from one application that is not in use , allocates about 1gb in virtual memory and you start a 1,8gb wav (1+1,8=2,8 that is bigger than 2gb max for apps) the os will translate, this 1,8gb to physical memory and at the some time it will release the data of the old application so that this 1,8 will fit.For sure this requires cpu assistance and will create clicks and pops.
 
On the above paragraph i said that 2gb can be translated in the best case, because in 32 bit windows this physical space of memory is the maximum that all the applications (user mode) can allocate.


I hope that the above are clear to understand because it is not so easy to explain.


PS: You will never come up with critical errors for OS, because when the physical memory running low, the operating system will release some space for the process that need this space. Don't forget that kernel modules will always have availiable memory in the 2gb kernel space.

 

[PeterSt]

cause english is not my native language

Here's another one !

It is more easy for me to explain, how the os acts, when an application requires memory from the system.

I don't know how you get this information (which I must just trust btw), but it is not said that what you know of it, is working correctly.
But before I get into your explanation, and before we have a misunderstanding, would you be so kind to choose from the below ?
In all cases the Swap file has been shut off ! All cases are 32 bit OS.

a. I installed 4GB of internal memory; when a program asks for e.g. 5GB, it can still run.
b. I installed 4GB of internal memory; when several programs together require e.g. 5GB, they can still run; maybe not all at the same time.
c. I installed 4GB of internal memory; if one - or all the programs together require more than 4 GB, an error is thrown.
d. I installed 4GB of internal memory; if one or all programs require more than the by the OS reported available physical memory, an error is thrown.
e. I installed 4GB of internal memory; if one or all programs require more than the by the OS reported available physical memory, an error is thrown when the reported 4GB limit of virtual memory is exceeded.
f. I installed 4GB of internal memory; if one or all programs require more than the by the OS reported available virtual memory, an error is thrown.

I have the hunch you will choose another option than I will.
I don't think it will be easy to choose (for me the same, because of the way I put it), and if you have the idea a comment has to come along with it, please do so (short if possible).

If you don't like it, never mind !

[astacus21]

The way the os acts is explained in microsofts technical papers. you can search for more info at microsoft technet.

For your a,b,c questions i'm not sure for the answer.But i think it will fail. Everythings it is going to work, if the availiable virtual memory (inside physical), is enough to fit the size of the process. I 'll make some experiment to see where is the limitation to me, as i use 4gb memory without swap.
For d,e,f i think that you sould get an error.

I think that everything is gonna work if it is below 2gb.

[astacus21]

Hi Peter

I make some tests with wav files and the biggest file i was able to play was about 1,8gb, which is near the limit of 2gb that is allowed for applications. It was a single wav about 170 min at 44.1/16 bit. This was with swap deleted.
After that i open some other applications so that the virtual memory get full with data and i try again with this 1,8gb wav. Guess what???
It' works so the procedure that i describe in the above posts, it works.

I've tried also with 2.4gb wav which failed.

After that i set back the swap file at 6gb of disk space and i restart the system so that the new pagefile was set to this size. Then i try to play the same wav 2.4gb but it still fails even at server 2008 x64. It was a surprise for me but after a while i remembered that when you start xxhe in 64 bit, it plays in an emulation mode of x32. So in this way you cant play anything above 2gb.

PS: I have said something wrong in the above posts. In this part that i say about a 2,5gb wav. So i 've made the corrections.
The right is that you cant have over 2 gb proccess in 32 bit. so if you have virtual memory filled with data from other apps and you try to play a file smaller than 2gb then this procedure take place.


**edit : i've found 2 links from MS that are related with the 2gb process:
for vista       http://msdn.microsoft.com/en-us/library/aa906211.aspx
for xp/2003   http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx

[PeterSt]

Ok, so you have been busy !

The way the os acts is explained in microsofts technical papers. you can search for more info at microsoft technet.

Yes, before I posted my large post yesterday I read into it all, and my post did not (try to) disobey that.
Btw, note that half of my post was about reasoning what TaskManager actually shows under "Swap file" (or Paging file, I translated it from Dutch), with the conclusion that that should read as Virtual Memory (in or excluding the Swap file, depening on whether it has been switched on or not). So, my earlier statement that Vista always keeps on using some swap file was wrong. Instead, it always keeps on paging to another part of memory (which is what you said from the beginning), but this is so because the OS can't directly use the full available physical memory.

The latter is my finding, or better : conclusion from everything in the white papers, because this is not described directly. Both "processes" -> 1. not being able to use the full memory and 2. paging to the part which is available - are described separately, and not in the combination I present : by kind of accident the memory which can't be used, can be used afterall because it can be used as additional virtual memory.

What you describe as "the kernel determines its size" (similar), is therefore only partly true. What will happen is that the kernel is able to determine unused memory space, and dedicate as paging area. Also note that not in all cases the memory can be fully utilized, which again is a matter of (wrongish) drivers.



Now, correct me if I'm wrong, but from your orginal subject we both seem to have our own subject. And oh, they are both as important I think.
Thus, your subject seems to be the explanation of how the OS deals with available physical memory vs. not available physical memory but which can extend to virtual memory ...
while my subject is the stupidity of that, and that it can't work (the other half of the large post from yesterday tries to explain that).

Well, I don't blame anyone who can't understand what I have written in that post, but, you can't counteract that with explaining the theories of operation. And please keep in mind : I knew them by the time I wrote that post (which was not so day before yesterday).
Important for you is that we agree, or at least that is how I see it. However, we only agree about the theory of operation, and not about the flaws following from that (remember, you didn't go into my subjects, and explained how it works instead). So :

So what I thought of it before (the topic I referred to) didn't change a single bit now knowing how it works, and you could say that I can see how things work without knowing it really.
Of course one thing changed : you *can* shut off paging to disk, hence no disk IO will occur after that for this reason.

Things may look trivial (the theory vs. the workout in practice), but it really is not IMO;
When you said that obviously the CPU is involved when the additional (!) virtual memory gets full, I claim that what happens there is b*llsh*t, and the CPU activity there is unnecessary and besides that *has* to work with the highest priority because of the processes happening.

The main subject to the latter, is the fact that it is not the normally available physical memory which gets full, but it is the paging area which gets full. And the most important is that this gets full not because of swapped out data, but because of prefetched data in case something will swap out.
I know, you said something like "you can't know what's in that area", but please trust me, I do. -> each byte which is user data which is necessary in the normal physical memory is copied to that additional memory as well (low priority) just in case the normal physical memory gets full.
Again, with some time this can be seen rather easily looking at taskmanager.

This all is rather unrelated to any theory of operations, because this happens with the normal swap file just the same. That is, this is what I expect but cannot see without additional investigation. So, what I expect is that when the additional virtual memory gets full, the swap file is in order, and any additionally needed memory in the paging area then goes to the swap file.
This means - in that case - that each user byte loaded goes to the swap file as well and takes I/Os. Also, as soon as that user byte is freed, again I/Os emerge to free that byte from the swap file. Now :

Since I now know better what happens when the swap file has been shut off, there's a kind of interesting conclusion (until proven wrong) :

As I told in the long post from yesterday, the 700MB or so which can't be utilized in my system (and which is so because of driver/mobo issues), actually is an advantage. Huh ?
Yes, I think so; Where my system starts off with 600MB used memory by the OS (could be 500MB depening on things) I have 700MB spare in there. Now, coincidentally, I have another 700MB of additional virtual memory, so both balance out. And keep in mind : each user byte in normal available physical memory goes to the additional virtual memory as well and I have 700 MB of memory for playing music without the stress of the additional virtual memory getting full and the operations to solve that. Note that in best circumstances (Mem box) this allows me to play to subsequent "full CD tracks" because I actually have 1400MB free, and they just can be utilized. However, when the second track is loaded, playback will be interrupted briefly near the end of track 1.

What I now may claim (must think about it further somehwat) is that the less additional virtual memory you have, the earlier stress time applies. Also, - and this might be the most important conclusion when it's true - when the swap file is just active, stress time does not occur (ok, unless the set limit of the swap file is reached).

astacus21, in order to judge these phenomena you get nowhere at proving the theory of operations to be right (or wrong for that matter); Instead you must do what I did, and just start playing tracks keeping in mind that one minute 44.1/16 takes around 10MB, and watch and watch and watch (TaskManager). You will notice that the green figure (the normal available physical memory actually in use) is not consistent with your thinking, which is caused by the Managed Code phenomenon, and you will also see that the derival of the green figure, the total virtual memory in use grows/shrinks linearly with the green figure, starting off with no user programs loaded (the, say, 600MB). Now, two happenings mat break the linearity :

1. Normal available physical memory gets full
2. Additional virtual memory gets full.

Ad 1.
Will cause anomalies which the OS is able to recover from (stress time).

Ad 2.
No problem, because the data is available in the paging area, which is in additional virtual memory.
Watchout though when 1. above happened first, and I claim an Out of Memory then.

Of further importance at judging the theory of operation vs. practice, is that this all is not about one single program (similar to your 2GB tests of last night), that it also is not about two programs, but that it is about one program dynamically allocating and freeing (huge amounts of) memory all the time, and that the OS takes care of the freeing, and one of the *reasons* to do that is reaching memory limits.
Looking closely, you can see that (somehow) the OS is not "smart" right after XX started playing (better : right after a reboot, and this *always* has bugged me no matter what kind of sound engine I used, no matter XP or Vista); Just start playing, and see the green figure grow and grow, until it reaches the physical limit (my 1350MB or so) and then it drops back. After that happened once, smartness pops in, and everything becomes predictable.

Side note : so, so many users (an I am one of them) reported (let alone those who did not report it) that things go wrong somewhere somehow at track 4 or 5 or 6 at a first playing session. In all cases there is no explanation (by me). But, I *know* the hard way of the OS needing to get rid of obsolete memory is in order there ...

Back to the case, I think I dare to say that I have found the solution hence differences with my system never having problems (swap file On) and a system like e.g. from the topic I pointed to (0.9u-12 --> Hiccups and Clicks and where Edward should try to set the Swap file ON.

Then there is this one :

Earlier in this topic I claimed that with XXHighEnd Audio playback, and having applied the settings as described in How I tweaked my Vista virtually dead, the Swap file will not be used (and where we by now have seen that it will occasionally be used at stress time situations). However :
I think this (Swap file not used) only applies for those who have an amount of additional virtual memory that is at least as large as the normal availabe physical memory, hence who have poor systems like mine. Hahaha. Thus, when you have far less (relative) space in the additional virtual mamory area, the limit in there is reached (long) before the normal available physical memory is full, and the Swap file *will* be used. Oh man, so where this encourages for shutting it off, the problems get only worse because of stress time.


astacus21, I realize that you all can't test this so easily with your 4GB of memory, and I even don't know how much of that additional virtual memory you have. Note though that if this is a lousy 700MB (which is lousy opposed to the 4GB) you hardly can encounter problems there, just because I don't with my 700MB in there.

The conclusions you draw to the 2GB and "one process" seem a bit dangerous to me, because I (so far) didn't bump into anything that descibed "one process". For your (further) mindsetting, think of this :

One 170 minute WAV (must be a hell of a bootleg btw) is not something we really need to play. But, a 60 minute 96/24 (or higher sample rate) is, and by heart this would be 1800MB. I can assure you that this 1800MB must be treated by one single process. But :
In order to get playback going, we must assume that this is needed twice the very least. In this case, this is dealt with by two threads, which I would call processes on this matter. But would they be to this respect ?

Sidenote : I plan to cut large (byte) tracks in pieces when needed, so actually it won't be a problem.

It was a surprise for me but after a while i remembered that when you start xxhe in 64 bit, it plays in an emulation mode of x32. So in this way you cant play anything above 2gb.

Yeah, that's a good one. I would never have thought of that. But be careful :
I can't look into it right now, but I am fairly sure that the process playing the role here (which would be XXEngine3) is *not* compiled for x86. I will let you know later.


Well, this was my typing for the day.