View Full Version : anyone work with 768+ mb of ram????
Simon Ravn
02-25-2001, 12:22 PM
I only work with 640mb of RAM, and on my system I notice that instruments take a lot longer to load, when my memory usage gets above 50% or so... very weird.
food4thought
02-25-2001, 02:13 PM
Windows 95/98/Me has known trouble with more than 512MB RAM installed. The problem lies with the virtual caching system and >512MB and can cause a series of further issues.
A simple way to avoid it is to set the VCACHE restrictions in the system.ini file. Or, a more elegant way would be to download the free utility Cacheman (www.outertech.com) and let it do it for you http://www.northernsounds.com/ubb/NonCGI/images/icons/smile.gif
I would suggest the VCACHE settings on any system with more than 128MB of RAM anyway, not only on those with over 512MB.
Finally, make sure the min/max vcache values are multiples of 512... e.g. not 32000 kbytes, but 32768 etc...
This should allow better use for large amounts of RAM by Gigastudio and other audio applications.
Experiment, and post your findings
SteveMitchell
02-25-2001, 08:17 PM
Food4thought - Actually, these memory problems don\'t exist in WinME as I\'ve stated several posts here in these forums.
The default block size used in WinMe was changed to accomodate larger memory maps.
apessino
02-25-2001, 10:53 PM
Sorry to disappoint you, Steve, but the aforementioned problems are alive and well in Windows ME.
One of my machines has 768MB, and I have had COUNTLESS problems getting it to work. Besides having to force the max vcache to 500MB (failing to do this will cause WinME to DIE a horrifying death, generally corrupting my boot drive in the process), I cannot possibly set ANY value for the \"min\" vcache, or Giga will take an eternity to load any gig file.
Also, the slowdown someone else reported also happens to me; at about 50% memory usage Giga becomes unbearably slow to load instruments, a problem connected with the vcache settings as well. Reducing the \"max\" from 500MB results in even worse slowdowns.
Overall, I still manage to make it work fine, and once the instruments are loaded everything (well, almost everything http://www.northernsounds.com/ubb/NonCGI/images/icons/wink.gif ) is OK, but I am dreaming of the day when these issues are finally solved.
By the way, a quick search for vcache in the Microsoft \"Knowledge Base\" will get you to a description of the problem, and Windows ME is listed as having the problem with its parents 95, 98 nad 98SE.
Cheers..
A-
------
Andrea G. Pessino (not female, just Italian)
Blizzard Entertainment
apessino@blizzard.com
chilcote.9
02-25-2001, 11:41 PM
I have a couple machines working well at 512mb of ram. I was wondering if going any further adds any real benefit (like up to 768 or even 1gb). I do run into limitations with polyphony on my system, but also, strangely enough with loading a lot of instruments. It seems I can\'t load more than about 1.5 - 2 gb of giga files at once. Is it a PCI bus throughput limitation? Perhaps it is probably a hard drive limitation (ibm-15gb platter-newest drives), or perhaps a 100mhz vs. 133mhz ram option (I run 100mhz fsb), or intel vs. amd (I run 800mhz), or chipset issue (I still run BX). I swear loading 16 xsample libraries that have all those variations is tough on your system. Also anyone have any trouble with windows 98se addressing 512+ mb of ram. It seems to actually run a tad bit slower with all this ram sometimes. Confused, so am I. Still getting work done, but perhaps someone knows that answers to these questions.
thanks
Take a look at the thread below, \"Too much CPU usage\".
SteveMitchell
02-26-2001, 08:03 AM
Hi Andrea - You absolutely right. I was wrong to confuse a memory heap management issue with the vcache issue mentioned in the article. Mea culpa.
BTW, if anyone is interested, the article is Q253912.
Steve Mitchell
The Classical MIDI Resource (\"http://www.classicalmidiresource.com\")
The CMR Players (\"http://www.mp3.com/cmrplayers\")
hancor
02-26-2001, 10:30 AM
Hi Guys,
More than 512mb ram necessary or possible
--------------------------------------------------------------------------------
When using winME, win98se, win98 or win95 I think you need to keep in mind the following from the Microsoft Knowledge Base:
support.microsoft.com/sup...&SPR=WINME
\"Out of Memory\" Error Messages with Large Amounts of RAM Installed
--------------------------------------------------------------------------------
The information in this article applies to:
Microsoft Windows Millennium Edition
Microsoft Windows 98 Second Edition
Microsoft Windows 98
Microsoft Windows 95
--------------------------------------------------------------------------------
SYMPTOMS
If a computer that is running any of the versions of Windows listed above contains more than 512 megabytes (for example, 768 megabytes) of physical memory (RAM) installed, you may experience one or more of the following symptoms:
You may be unable to open an MS-DOS session (or command prompt) while Windows is running. Attempts to do so may generate the following error message:
There is not enough memory available to run this program.
Quit one or more programs, and then try again.
The computer may stop responding (hang) while Windows is starting, or halt and display the following error message:
Insufficient memory to initialize windows. Quit one or more memory-resident programs or remove unnecessary utilities from your Config.sys and Autoexec.bat files, and restart your computer.
CAUSE
The Windows 32-bit protected-mode cache driver (Vcache) determines the maximum cache size based on the amount of RAM that is present when Windows starts. Vcache then reserves enough memory addresses to permit it to access a cache of the maximum size so that it can increase the cache to that size if needed. These addresses are allocated in a range of virtual addresses from 0xC0000000 through 0xFFFFFFFF (3 to 4 gigabytes) known as the system arena.
On computers with large amounts of RAM, the maximum cache size can be large enough that Vcache consumes all of the addresses in the system arena, leaving no virtual memory addresses available for other functions such as opening an MS-DOS prompt (creating a new virtual machine).
WORKAROUND
To work around this problem, use one of the following methods:
Use the MaxFileCache setting in the System.ini file to reduce the maximum amount of memory that Vcache uses to 512 megabytes (524,288 KB) or less.
For additional information about how to use the MaxFileCache setting, click the article number below to view the article in the Microsoft Knowledge Base:
Q108079 32-Bit File Access Maximum Cache Size
Use the System Configuration utility to limit the amount of memory that Windows uses to 512 megabytes (MB) or less.
For additional information about how to use the System Configuration utility, click the article number below to view the article in the Microsoft Knowledge Base:
Q181966 System Configuration Utility Advanced Troubleshooting Settings
Reduce the amount of memory that is installed in your computer to 512 MB or less.
STATUS
Microsoft has confirmed this to be a problem in the Microsoft products listed at the beginning of this article.
MORE INFORMATION
Vcache is limited internally to a maximum cache size of 800 MB.
This problem may occur more readily with Advanced Graphics Port (AGP) video adapters because the AGP aperture is also mapped to addresses in the system arena. For example, if Vcache is using a maximum cache size of 800 MB and an AGP video adapter has a 128-MB aperture mapped, there is very little address space remaining for the other system code and data that must occupy this range of virtual addresses.
Additional query words: 768MB
Keywords : kberrmsg osr1 osr2 diskmem win95 win98 win98se kbWinME
Issue type : kbprb
Technology :
Last Reviewed: December 14, 2000
© 2001 Microsoft Corporation. All rights reserved. Terms of Use.
Hope this clarifies the issue.
Regards
Hans
apessino
02-26-2001, 01:28 PM
Yup.. that\'s all true, sadly. http://www.northernsounds.com/ubb/NonCGI/images/icons/wink.gif
Also, to clarify the whole memory usage by GigaStudio issue, from my experience it works as follows:
GigaStudio checks the amount of physical memory installed in the machine, then reserves about 100Kb _per sample_ to gain quick access to the attack portion of the sounds. Stereo samples take up twice that amount. No matter how big the samples actually are on disk, each one takes up one \"unit\" of Giga-space. As the sound is played and the attack portion of it is exhausted, Giga begins to stream from storage, so that samples of arbitrary length can be played back.
In other words, a machine with 256Mb will load about 2500 mono or 1250 stereo samples, regardless of their actual size on disk.
This means that my 512Mb machine can load 2500 stereo samples and my 768Mb machine 3750. A \"dream machine\" with 2Gb of RAM would be able to load 10000 stereo samples.
This is, by far, the biggest limitation of the Giga system, in my opinion. With multi-layer, chromatically sampled libraries I run out of memory WAY before I run out of polyphony.
Additionally, as usage of memory by Giga gets more intensive (read: large portions of physical memory \"locked\" by Giga to keep its attack samples) conflicts with other processes needing memory (such as the horrible vcache module) affect performance, cause pops and clicks, and produce serious stability problems.
I think the system above could be improved, for example: if I have a REALLY fast drive, like a dedicated UltraSCSI 160 or a striped RAID, then why not give me the option to reduce the size of the sample-unit used by Giga? If I could specify 50Kb instead of 100Kb for the attack portion, and my machine is fast enough to handle it, I could instantly double the amount of samples I can have ready to trigger!
And there you have it.. http://www.northernsounds.com/ubb/NonCGI/images/icons/wink.gif
Cheers.
A-
---------
Andrea G. Pessino (not female, just Italian)
Blizzard Entertainment
apessino@blizzard.com
Having read the above and being aware of Window problems with more than 512 memory, bottom line, is it worth it to get as much memory as the motherboard will hold along with limiting VCache min/max to 512? Seems the above comments conflict saying Giga runs slower/takes longer to load if you go over 512 on the motherboard. With memory so cheap, who can give us the bottom line whether to stop at 512 or go for broke loading up the motherboard?
hancor
02-27-2001, 02:03 AM
Bottom line, DO NOT upgrade past 512MB of RAM, unless you like dealing with unstable systems. Wait until GS160 is available for Windows 2000 then upgrade the OS, RAM and GS160.
Regards
Hans
hancor
02-27-2001, 02:10 AM
BTW the suggestion of going with SCSI drives is a good one. I\'m running two drives, both with 8MB of onboard SRAM. Your best bet is the Quantum Atlas 10KII in the 18.4GB capacity. Using the Adaptec Ultra160 SCSI controller and the drives have allowed me to record into LAWP without too much trouble. IDE in this regard is like a garden hose compared to the SCSI solution which is like the 1meter/36\" storm pipe!!
Its all about throughput!
Regards
Hans
SteveMitchell
02-27-2001, 06:58 AM
<BLOCKQUOTE><font size=\"1\" face=\"Verdana, Arial\">quote:</font><HR>Bottom line, DO NOT upgrade past 512MB of RAM, unless you like dealing with unstable systems...<HR></BLOCKQUOTE>
With all due respect Hancor, that is patently not true. With RAM being so cheap, I run two machines each with 1Gig of RAM on WinME, with VIA chipsets no less. The article above refers to a limitation in Win9x caching system being limited to 800 megabytes (on purpose as to not interfere with a memory map from AGP)- the cache and free memory heap are two entirely different things. This concerns ONLY the cache -WinMe and GSt running on WinMe will use every bit of memory you throw at it.
Steve Mitchell
The Classical MIDI Resource (\"http://www.classicalmidiresource.com\")
The CMR Players (\"http://www.mp3.com/cmrplayers\")
[This message has been edited by SteveMitchell (edited 02-27-2001).]
chilcote.9
02-27-2001, 08:37 AM
So, it seems, as I started this thread, some good discussion has occurred. You people always provide interesting counterpoint to the solution
Correct me if I\'m wrong, but I now deem it ok to add ram to = 768 mb (or more) to the system. We just have to watch it... I\'m really just interested in having all 16 channels loading 16 x-sample instruments and then triggered remotely. You know, use the system, but not kill it past where it is going to crash consistently.. Thanks, people.
hancor
03-01-2001, 03:56 PM
With all due respect to my learned friend Steve Mitchell; perhaps he can explain the following quotation to me.
In Win9x, \"Calling \'HeapAlloc\' and requesting
a block larger than 256MB is considered by Windows 98 an error - the call fails.\"
Programming Applications for Microsoft Windows 4th Edition, PartIII:Memory Management, Chapter 18:Heaps p.663
Author: Jeffrey Richter c.1999 Microsoft Press
While the win32 API can address a full 4GB of
memory this is only fully realized under NT or Windows 2000. It is not a question of whether you can physically populate your motherboard with RAM, or whether RAM prices are currently cheap. It is a question of whether the OS of choice, in this case Win9x,
can address all the memory space, through one application process, namely GigaStudio160. The difficulty in Win9x is that it is a mixed 16bit and 32bit enviornment. It is the legacy of 16bit heaps that makes memory addressing somewhat more difficult. Given the above quotation I would mark down the assertion that win9x \"will use every bit of memory you throw at it\", down as doubtful. Perhaps a comment or two from our friendly programmers over at Nemesys would be instructive as to the methodology/constraints they have laboured under.
In my original post I indicated the the Knowledge Base article was something to keep in mind as you evaluate the program needs. I note the minimum for the GS160 is 128MB of RAM, while the recommendation I made was to delimit under win9x to 512MB as this is 4 times the required minimum. Instead of going for another 512MB of RAM, I would be adding to my instrument library.
When GS160 is coded for Windows 2000, I would
then upgrade the program, OS, and RAM provided one\'s sound card has a stable Windows 2000 driver.
Regards
Hans
SteveMitchell
03-01-2001, 06:14 PM
Hi Hancor - This limitation is covered in KB Article Q198959, and applies to Win95, Win98, but not to Windows Me, at least according to Microsoft.
I did buy more samples, and my standalone GSt machine had only 768 Meg of RAM, and when I added them to my performance, they wouldn\'t load. I added another 256 Meg, to up it to 1024 Meg, and the new samples loaded as well. With results like this, I can\'t help but think that all of the memory is being used.
Steve Mitchell
The Classical MIDI Resource (\"http://www.classicalmidiresource.com\")
The CMR Players (\"http://www.mp3.com/cmrplayers\")
[This message has been edited by SteveMitchell (edited 03-01-2001).]
hancor
03-02-2001, 01:22 AM
Hi Steve,
The article you quote, is correctly identified as pertaining to Win95 and Win98.
I believe \"chilcote.9\" in his original post at the start of this thread phrased his query with: \"...anyone have any trouble with Win98SE addressing 512+ mb of ram.\"
Hence my reference, to the programming text as it pertains to win98. Thus to make the statement that my argument is \"patently not true\"; would be somewhat overstating the case at hand. One cannot merely assert that if it works in one OS it will work in another; notwithstanding that the OSs are related. It would appear that the user would then have to make a decision:
1. Upgrade random access memory, AND upgrade OS to WinME to get the memory addressing required; given your positive reports.
2. Wait until the program is coded for Win2000 and then upgrade OS, RAM, and application knowing that the maximum RAM allocation is 4GB and not fettered by 16bit code.
Knowing full well that WinME is the \'end of the line\' for win9x/16bit code; I would be looking at Win2000 as the most effective
allocation of expenditures because the support will be there long after Win9x/ME are retired. Notably, Nemesys on their site are already taking email addresses for the next version which will be coded on the NT5 kernel.
Regards
Hans
SteveMitchell
03-02-2001, 07:11 AM
Hi Hancor - I completely agree with you. The hybrid 32bit/16bit system of Win9x is WAY past its sell-by date. However, the WDM system of writing drivers is very slow to catch on. I\'m afraid that Windows XP will be out before many of these hardware mfgs are ready with WDM drivers for their cool products. That\'s kinda why I push WinMe - it\'s a 9x-based OS, and it handles big memory OK.
Steve Mitchell
The Classical MIDI Resource (\"http://www.classicalmidiresource.com\")
The CMR Players (\"http://www.mp3.com/cmrplayers\")
Mr. Chance
03-04-2001, 08:56 AM
I think that sums it up well Steve. If I were building a new DAW today I would install ME. It\'s the best option currently available.
Chance
Bottom line then seems to be: run Windows ME as the operating system and fill your motherboard with as much ram as it will hold or you can afford. If anyone sees it some other way, chime in here.
Cheez
03-05-2001, 08:25 PM
Just want to add that I run 2 machines with Windows ME. My dedicated Giga PC has 98lite installed and it seems to be more stable than my other pure Windows ME PC.
chilcote.9
03-06-2001, 08:11 AM
I don\'t think any win 9x, or me can address more than 512 mb of memory.
What value of maxfilecache do we need?
Come on nemesys, we need w2k????
A REGISTER ARTICLE---------
WHAT DO YOU GIGA USERS THINK???
------------------------->
WinME can\'t handle more than 512 megs of memory
By: Andrew Thomas
Posted: 24/11/2000 at 09:51 GMT
Like world+dog, we were obviously looking for something to beat up on Intel with following the launch of the P4. Unlike most of the planet, we reckoned that an old BIOS shipped with a couple of old mobos wasn\'t much of a story.
We much preferred a glitch we\'d discovered a couple of weeks ago that appeared to be a rerun of the Caminogate RDRAM cockup. And, unlike some folk, we actually did some research before loosing the hounds on Chipzilla.
Our sample P4 and D850GB mobo, supplied with Windows ME installed, ran perfectly happily with the 256MB of RDRAM shipped to us. It also ran perfectly happily with the 512MB of RDRAM that Kingston sent us. Only when we tried to run both together did we hit problems.
No matter which configurations we tried, the system would not run with 768MB of memory, returning the error message: \"There is not enough memory available to run this program. Quit one or more programs, and then try again.\"
768MB \"not enough\"? Blimey.
At first we considered the obvious options - unsupported RIMMs, mixing ECC and non-ECC memory, phases of the moon and so forth. This was tantalisingly familiar territory: an Intel RDRAM mobo that didn\'t work properly with fully-populated RIMM slots.
But the answer turned out to be far more mundane: Windows ME simply can\'t cope with more than 512MB of memory.
And neither can any other Win9x variant.
And it\'s a \'feature\'. It transpires that Win ME, Win98 and Win95 cannot deal with main memory sizes in excess of 512MB. The Microsoft Knowledgebase entries on the subject (dating back a few short weeks) contain the following fascinating facts:
\"The Windows 32-bit protected-mode cache driver (Vcache) determines the maximum cache size based on the amount of RAM that is present when Windows starts. Vcache then reserves enough memory addresses to permit it to access a cache of the maximum size so that it can increase the cache to that size if needed. These addresses are allocated in a range of virtual addresses from 0xC0000000 through 0xFFFFFFFF (3 to 4 gigabytes) known as the system arena.
\"On computers with large amounts of RAM, the maximum cache size can be large enough that Vcache consumes all of the addresses in the system arena, leaving no virtual memory addresses available for other functions such as opening an MS-DOS prompt (creating a new virtual machine).
\"This problem may occur more readily with Advanced Graphics Port (AGP) video adapters because the AGP aperture is also mapped to addresses in the system arena. For example, if Vcache is using a maximum cache size of 800MB and an AGP video adapter has a 128MB aperture mapped, there is very little address space remaining for the other system code and data that must occupy this range of virtual addresses.\"
And here are the three suggested workarounds:
\"1. Physically remove any memory in excess of 512MB [!]
\"2. Use the System Configuration utility to limit the amount of memory that Windows uses to 512MB or less.
\"3. Use the MaxFileCache setting in the System.ini file to reduce the maximum amount of memory that Vcache uses to 512MB (524,288 KB) or less.\"
And the unspoken fourth solution: upgrade to Windows 2000.
Knowledgebase also admits that the addressing restriction has been identified as a failing in Windows. Installing Win2K obviated the problem. All 768MB ran faultlessly.
So if you think that adding extra memory will make your Win 9x system run faster, the answer is: it will, provided you don\'t exceed 512MB. With today\'s systems more than capable of exceeding this size, and with wallets capacious enough to purchase more than 512MB of RDRAM, Win 9X/ME suddenly appears rather passé.
Scary thought: how much memory will Office 2001 require? ®
SteveMitchell
03-06-2001, 10:21 AM
Hi Chilcote.9 - Hmmmm, based on the evidence I\'ve seen and experienced, I would have to say that Andrew is incorrect in some respects, at least concerning Millennium, and is mis-interpreting the article. The issue addressed in the article concerns VCACHE, and VCACHE alone. If you remember from the days of old hardware, a cache was used to allow you to re-use code and to avoid reloading code from a slow harddrive or CD. VCACHE is the dynamic cache that Win9x (including Millennium) uses to do the same thing. It\'s dynamic because if ANY application requests RAM, and VCACHE is using any of that block in the main heap, then VCACHE relinquishes this RAM to the Application. The limitation of VCACHE to 512 Megs only limits the size that VCACHE can reach for the reasons the article stated. It does not limit the size of RAM Millenium can handle. Again, I\'ve got two machines using 1 GIG of RAM, using VIA chipsets, GSt continues to use every bit of it.
Steve Mitchell
The Classical MIDI Resource (\"http://www.classicalmidiresource.com\")
The CMR Players (\"http://www.mp3.com/cmrplayers\")
[This message has been edited by SteveMitchell (edited 03-06-2001).]
chilcote.9
03-07-2001, 10:35 PM
Okay, steve mitchell.
You obviously have great success with win me.
I prefer to run win98se because in my experience with 8+ machines all different, it runs more stable, networking actually works, and win me does more stuff in the background than hell which take up system resources. Even system restore crashes, and messes up, removes files without asking..etc.
so with win 98se, and 768mb of ram, as I started this thread.........
I would like to know whether any ones experience that performing optimizations on the vcache settings has helped them.
Do people use cachemem 4?
IN response to this....
Use the MaxFileCache setting in the System.ini file to reduce the maximum amount of memory that Vcache uses to 512MB (524,288 KB) or less--------------so what do you add to the system.ini--------exactly and why?
w2k is really cool, but very non-robust for audio and sequencing, soft synths,etc..
w2k has No giga---whatever, but has a much more stable interface than any win9x/me stuff, but a lot more incompatibilities. For instance in my case, I also run a dididesign isa samplecell pc card, and it does not run under w2k at all.
I can regurgitate other examples at will, but why?
I run gigasampler, not gigastudio.
I truely believe this to be the way to get any real work done.
I load around 2gb of samples on 16 channels on a dedicated computer and sp-dif them back into tracks to mix down on my delta 10/10 main dedicated audio/sequencing computer.
win me and win 2k suck..........
go back to win98se
Other peoples thoughts on this???
SteveMitchell
03-08-2001, 07:27 AM
<BLOCKQUOTE><font size=\"1\" face=\"Verdana, Arial\">quote:</font><HR>--------------so what do you add to the system.ini ----exactly and why?<HR></BLOCKQUOTE>
In the SYSTEM.INI, find the section called [Vcache], and insert this entry underneath:
maxfilecache=524288
This will tell VCACHE to only use 512 megabytes of SYSTEM MEMORY for its cache. This leaves plenty of address space for other components.
<BLOCKQUOTE><font size=\"1\" face=\"Verdana, Arial\">quote:</font><HR>w2k is really cool, but very non-robust for audio and sequencing, soft synths,etc.. W2k has No giga---whatever, but has a much more stable interface than any win9x/me stuff, but a lot more incompatibilities<HR></BLOCKQUOTE>
Absolutely true - you\'ll get no argument from me on that. Windows 2000 support is only half of the equation though. Nemesys could get their Win2000-compatible code out there tomorrow, but with so little REAL support for the WDM system of writing drivers, Nemesys would be sitting out there
pretty much alone, or with little company, and not making much money. (WDM stands for Windows Driver Model, and means that the driver will usually work on the WinNT4/Win2000 platform as well as the Win9x platform, the platform where the $$$$ is). Currently, there are only two mfg\'s that I know of who\'ve written WDM drivers for their hardware - Egosys and Creative. I\'m sure that there are more, but I can\'t think of any right now. Egosys is even beta-testing a WDM-GSIF driver now for their line of audio cards. That\'s pretty cool, but again, that\'s only one manufacturer.
I have a WamiRack, so I don\'t need to hound EgoSys about a driver. But others, if your soundcard doesn\'t have a WDM driver yet, get on \'em to write one. Without it, YOU won\'t have Win2000 support ever. When Nemesys figures that there\'s good hardware support out there, they just might kick their Win2000-code production into high gear.
Part of that Nemesys high-gear operation could even include them writing a base-driver for GSt to run on Win2k, which would require mfgs to only write a mini-driver for their specific hardware.
Steve Mitchell
The Classical MIDI Resource (\"http://www.classicalmidiresource.com\")
The CMR Players (\"http://www.mp3.com/cmrplayers\")
lamoore
03-08-2001, 07:59 AM
Here\'s what the vcache setting in system.ini are all about, courtesy of IQS:
Read-Caching
By default, Windows 95/98 caches all disk reads to RAM. Normally read caching can be an advantage in some audio streaming programs. Problems can occur in some cases, however, when Windows 95/98 dynamically resizes the amount of space allocated for the read-cache buffers. This can cause audio glitching during playback.
To Limit the Maximum File Read-Cache Size:
* This procedure requires a good working knowledge of the Windows 95/98 environment. If you\'re not comfortable with the following steps, solicit the help of someone well-versed in the Windows 95/98 platform.
1. Using Windows 98 Start>Run type msconfig and click OK, navigate to the System.ini tab.
2. Scroll through the file looking for a section labeled [vcache] and click on the + sign to reveal its contents.
3. Create a blank line under the [vcache] heading and type the following:
MaxFileCache = 4096.
If this entry already exists, just change the size value. Make sure the upper case and lowercase letters are maintained, otherwise this line will not work.
* This limits the maximum file cache size to 4096 Kilobytes (4 Megabytes). You can experiment with different sizes, but the size specified should be in increments of 1024 and it is recommended that the size not be made less than 2048.
Apply the changes and close msconfig. Restart Windows 95/98 for this change to take effect.
I\'ve had excellent results with 768MB SDRAM and a system.ini vcache setting of MaxFileCache=8192
Experiment around with multiples of 1024 until you find what works for your system.
There are several areas in Win98 that affect Gigasampler/Gigastudio performance or any audio streaming program for that matter. Virtual memory size, file write caching, double buffering, video cards, computer role, background processing, limiting the read caching, all the way to how your data drives are formatted!
A common complaint I hear in my Giga-consulting business is, \"When I load up several Gigabytes of samples into Gigastudio or I get above 70% on the Memory bar I hear glitches\". Reality check for everyone out there...Gigastudio is not the end-all. Yes, it\'s an awesome program yet I caution you to do the math. If you load 2 Gigabytes of samples you are, in essence, loading enough material to stream 64 Roland 760\'s worth of samples on one computer, in real time, reading everything from one hard drive (99 times out of 100) with a read/write head doing major gymnastics in order for you to play the sequence you made of your latest symphony. I\'d say that pretty awesome, and there\'s still a long way to go as computing technology continues to advance. Be patient. Buy a second computer or install a server with 1000Mbps and numerous Ultra-160 SCSI drives, hang in there, and keep tweaking until your computer begs for mercy.
------------------
http://members.loop.com/~lamoore (\"http://members.loop.com/~lamoore\")
chilcote.9
03-08-2001, 10:00 AM
I\'m getting conflicting replys to my question.
fill in the blanks..........
What do you guys put as good settings?
in (system.ini)
[vcache]
MinFileCache=
MaxFileCache=
ChunkSize=
Anyone?
For instance, www.outertech.com (\"http://www.outertech.com\") makes a program called cachemem 4, that produces the following settings, when win98, multimedia user is selected.
[vcache]
MinFileCache=6144
MaxFileCache=18432
ChunkSize=1024
ok, this I understand lamoore..........
I\'ve had excellent results with 768MB SDRAM and a system.ini vcache setting of MaxFileCache=8192
??I don\'t understand stever mitchell\'s settings????????????
In the SYSTEM.INI, find the section called [Vcache], and insert this entry underneath:
maxfilecache=524288
huh???
These conflict, any solutions?
SteveMitchell
03-08-2001, 10:40 AM
Hi Chilcote.9 - In your previous message (and the quote I included), you asked how and why. I\'m sorry that it wasn\'t clear. If you wanted to limit the VCACHE size to 512 Megabytes, then that\'s the entry you\'d use.
Steve Mitchell
The Classical MIDI Resource (\"http://www.classicalmidiresource.com\")
The CMR Players (\"http://www.mp3.com/cmrplayers\")
Cheez
03-08-2001, 07:17 PM
Correct me if I\'m wrong, but isn\'t the vcache setting be set to 25% of your RAM size?
Hence for me (512 MB of RAM), my vcache is set to 25% of 512 = 128 MEGABYTE which is = 131072 KILOBYTE (ie 128 X 1024). Remember that vcache is in Kb and not Mb. I\'m getting maximum polyphony with this setting (ie 160).
In previous posts, however, others are getting conflicting results with different vcache settings. Can\'t explain that. I guess you\'ll just have to go by trial and error and see what works best for you.
SteveMitchell
03-09-2001, 07:07 AM
Hi Cheez - In reality, there is no limit to VCACHE up to the 800 Meg Max mentioned in that Microsoft Knowledge Base article Q253912 unless MAXFILECACHE=xxxxx is present in the SYSTEM.INI. I\'ve never heard of the 25% rule, but I think GS and GSt maintain their own cache so-to-speak buy leaving all Gigs loaded in memory in amounts up to available system RAM, so VCACHE may not be an issue here.
This discussion had recently centered on machines with very large memory heaps - 768 MB and above. Obviously, 512 Meg is no small amount either, but that amount is at the limit of Win9x for memory-handling reasons. Millennium is not affected by this limitation in as far as the main memory size. As 512 MB RAM per machine and more became more commonplace, this fact exposed limitations involving VCACHE for the first time.
I never wanted to raise the ire of anyone here, I was just trying to help iron out what I believe and evidence shows some misconceptions regarding System Memory limitations and VCACHE limitations.
Steve Mitchell
The Classical MIDI Resource (\"http://www.classicalmidiresource.com\")
The CMR Players (\"http://www.mp3.com/cmrplayers\")
lamoore
03-09-2001, 01:01 PM
This doesn\'t have to be confusing guys.
All you\'re doing here is limiting how much RAM Windows can grab when it\'s doing it\'s read caching. The key is that you don\'t want Windows to grab too much RAM where it interferes with all the sounds you have loaded into RAM for Gigastudio to access. What that number is, in the end, is dependent on each programs use of RAM, and there has to be a balance with how many sounds you usually have in your Giga Performances. If you\'re running at 80%, then a big vcache value is going to conflict and you may get clicks and pops as the OS keeps redistributing the data in RAM. Just by the fact that you\'re limiting the vcache should improve Gigastudio performance.
If you just want a number, try MaxFileCache = 4096 for 512MB and MaxFileCache = 8192 for over 512MB and see how your performance is. I run with a setting of 8192 for a 768MB RAM system and Gigastudio runs great.
If you want to try an experiment:
set vcache to 256MB (MaxFileCache = 262144) and try to run Gigastudio. If the program works horribly or crashes, reboot in Safe Mode and reset the vcache value to half, reboot, reload Gigastudio (click No when it asks if you want to run diagnostics), and notice how the program works with the new settings. Keep going until you get to the minimum of 2MB (MaxFileCache = 2048). You\'ll know when you find the number that works well with Gigastudio on your system.
I think I\'ll test this theory out on my Gigastudio http://www.northernsounds.com/ubb/NonCGI/images/icons/smile.gif
Good luck.
------------------
Lennie Moore
http://members.loop.com/~lamoore
Powered by vBulletin® Version 4.1.10 Copyright © 2012 vBulletin Solutions, Inc. All rights reserved.