I'm jealous. 

If you think a DAW is tough on a PC, try a video NLE... yeesh!

sharke

John 


No it can't. A 32 bit OS can only access 4 GB of memory. It is not on a per program basis. 

If it were a 64 bit OS it can allocate up to 4 GB to each 32 bit program.     

A little cursory research has shown this to be a myth. Not that Windows 32-bit will access more than 4GB, because that part is correct. However it turns out that the 4GB limit is not an inherent property of 32-bit systems, but rather a limitation that Microsoft hardwired into Windows. You can only use 4GB in 32-bit Windows because that's how much Microsoft have licensed you to use with their OS. And apparently it's hackable, although not advised.  


http://www.geoffchappell....ows/license/memory.htm 

The fact that the code to address >4 GB of memory was deliberately disabled in consumer versions of earlier Windows operating systems is a pretty well explored issue. It is not impossible to logically address amounts of memory > 4GB using a 32 bit OS, and MS did write code for that in server editions of earlier systems, when 64 bit native CPU's were not routinely used.  Nonetheless, if you install a Windows 32 bit operating system, you will not be able to address > 4 GB unless you do some major patching, which is quite beyond the average user, and such hacks are not supported by most software developers now.

If you want to run more memory, use an OS that is designed to do so. 

However it turns out that the 4GB limit is not an inherent property of 32-bit systems, but rather a limitation that Microsoft hardwired into Windows. You can only use 4GB in 32-bit Windows because that's how much Microsoft have licensed you to use with their OS.

Sorry, but that's a load of BS. It's because computers are binary and 2 to the 32nd power is about 4 billion so that's the limit of the amount of space a 32 bit system can address.

Apparently not, see here, though I thought so as well. It's true for the 8086 memory model but you can get around that with memory mapping which Microsoft did for its server os's.

Interesting bit from the article :

"However, by the time Windows XP SP2 was under development, client systems with more than 4GB were foreseeable, so the Windows team started broadly testing Windows XP on systems with more than 4GB of memory. Windows XP SP2 also enabled Physical Address Extensions (PAE) support by default on hardware that implements no-execute memory because its required for Data Execution Prevention (DEP), but that also enables support for more than 4GB of memory.

What they found was that many of the systems would crash, hang, or become unbootable because some device drivers, commonly those for video and audio devices that are found typically on clients but not servers, were not programmed to expect physical addresses larger than 4GB. As a result, the drivers truncated such addresses, resulting in memory corruptions and corruption side effects. Server systems commonly have more generic devices and with simpler and more stable drivers, and therefore hadn't generally surfaced these problems. The problematic client driver ecosystem led to the decision for client SKUs to ignore physical memory that resides above 4GB, even though they can theoretically address it. "

Virtual addressing. Anybody who remembers emm386 in DOS days this is what is happening. This happens at a minor CPU cost and yes possible null pointer errors in device driver software.

Paul P


Apparently not, see here, though I thought so as well. It's true for the 8086 memory model but you can get around that with memory mapping which Microsoft did for its server os's.

Interesting bit from the article :

"However, by the time Windows XP SP2 was under development, client systems with more than 4GB were foreseeable, so the Windows team started broadly testing Windows XP on systems with more than 4GB of memory. Windows XP SP2 also enabled Physical Address Extensions (PAE) support by default on hardware that implements no-execute memory because its required for Data Execution Prevention (DEP), but that also enables support for more than 4GB of memory.

What they found was that many of the systems would crash, hang, or become unbootable because some device drivers, commonly those for video and audio devices that are found typically on clients but not servers, were not programmed to expect physical addresses larger than 4GB. As a result, the drivers truncated such addresses, resulting in memory corruptions and corruption side effects. Server systems commonly have more generic devices and with simpler and more stable drivers, and therefore hadn't generally surfaced these problems. The problematic client driver ecosystem led to the decision for client SKUs to ignore physical memory that resides above 4GB, even though they can theoretically address it. "

+1


Good one. I'm sure most of the earlier pre 64-bit Pentiums and/or their memory controllers couldn't/wouldn't address the full 128GB either. Given that, that's little reason to extend 32-bit addressing capability further as it is already handled by nicely by 64bit processors, and blocking unused memory eliminates all sorts of nasties.

As the article mentioned, the resources used to support larger addressing on 32-bit would be wasted on the market where 32-bit operation is headed:on limited memory systems it would actually be a hindrance.

What does any of that have to do with the fact that 32 bit OSs access only 4 GBs of memory? 

You guys can argue about it till the cows come home that wont change anything. 

If you want to access more than 4 GB of ram you need to go with a 64 bit OS. 

Swiller


Hi, 

I have just invested in a new pc and thought I would share my experience with running sonar x2.
Hopefully this may help others in diagnosing why there may be problems and how much a better speccd pc can be to all of the components of a studio.


I had a 2 year old quad core and sata 2 7200rpm disk drive with 8gb of DDR ram 2. On paper it should be good enough to run x2 no probs and it ran x1 fairly well, no crashes and x2 it had problems which have been mentioned here by many members. White screens, stopping of playback for no reason, breverb instances blanking out etc etc.


With a new spec computer I am having absolutely no problems with x2. Using exactly the same arrangements, plugins, audio tracks etc. components apart, the only difference to my previous setup is the fact that I only installed x2 on it he new one, not x1 and 8.5 as with previous pc. In fact when I uninstalled x1 after x2 installed on the old one, and x 2 wouldn't load half of my arrangements.




I paid a grand for this from novatech.. Old pc in brackets...


I3700k 3.5ghz. (Quad core 2.5ghz) 
Ssd 240gb sata3 port (None)
Sata 3 2tb hd <4ms (Sata 2 640gb 7200rpm)
16gb  ddr3 1600hz. (8gb ddr2)
Dvdrom. (Same).

2gb cheap and cheerful gt 640 ( 1gb nvidia )


Soundcard is a 8i6. On the new pc 3ms setting runs fine. On old, it would struggle at 6ms. It makes me realise the Scarlett is great, it just didn't have the right pc running it.


I put the fact that I am having no errors at all or spikes down to.. In order of preference..


1) running sonar from a ssd drive.
2) the additional speed of the ram.
3) no previous versions of sonar on the hard disk. Clean install. I think this is important.
4) better USB bus on the motherboard for the soundcard and peripherals.
5) processor .


So then I put the ssd disk in the old pc with the same ram in a sata 2 port and it appeared to be stable for a good few hours. No problems. Maybe that's all the old pc  needed. Food for thought .


So if helpful for anyone having troubles with x2 I would, certainly recommend a ssd and getting some quick ram in there as a cheap option which will benefit the pc and not break the bank. I would also recommend installing sonar x2 on a seperate hard disk , or uninstall older versions of sonar before you install x2 on that disk.


Hope this helps people who are having problems. What would be interesting to see if any people are having crash problems using ssd and clean install of x2 and 16gb of 1600 ddr3 in an i7 system. If not then these glitches and crashes must be related to the hardware it is running on or the precious installs of sonar on systems, or both.


Very glad I bought the new pc  it and x2 is now running really fakin quick and smooth. Please post up any other knowledge or experiments using sonar x2 on different pcs or hardware configs. 

I purchased my StudioCat i7 three years ago and have had absolutely no problems.  This is a dedicated DAW that is running Windows 7 Ultimate x64.  Sonar X2a is completely stable for me.

John


What does any of that have to do with the fact that 32 bit OSs access only 4 GBs of memory? 

It was addressing the very reasoning behind the fact that 32-bit OS's are limited to 4GB of memory. 

It's so related to the discussion that it's consanguinity could get it arrested.