Joe, I have seen the really slow instrument loading on my system after 50% (I have 1GB). I do not know of a solution, so if you find anything out, please let me know. I am experiencing other problems with upgrading from 512MB to 1GB, but Nemesys hasn\'t gotten back to me yet.
Related topics have probably been covered a few times already, but anyway I\'d like to ask if anyone has seen (and possibly solved) the following problem:
I use 1.5GB of SDRAM on a machine with a thunderbird 1.4 and an ASUS A7V(133). After running Windows for a little while, access to the boot harddisk becomes insanely slow. The same happens when loading instruments in GS after memory is filled to about 50% (Instrument playback is fine, though).
Reebooting makes those problems go away, but only for a few minutes.
I use the recommended modifications in System.ini:
If I remember correctly, Simon noted that, too, in an earlied thread. Has anybody found a solution to this problem?
Yes there is no reason to set the VCAche to 512MB - above 30-60MB you won\'t notice the difference. What MS suggests if you can\'t get Windows to work with more than 512MB, is to allocate no more than 512MB for Windows to use - that is not the VCache setting. I don\'t remember how you do it, but it is explained on MS\'es pages.
But if you do that, won\'t that prevent GigaStudio from using that memory as well?
I have to figure out why I can get GigaStudio to run perfectly with 512 MB but not with 1GB. I can\'t currently record anything longer than about 90 seconds because of this audio glitch every 2 minutes, and I haven\'t heard anything back from Nemesys Tech Support.
[This message has been edited by Jamieh (edited 10-07-2001).]
I believe there is a fix for your 2 minute audio glitch. Maybe I\'m thinking of something else but I\'ve read on this forum if that starts happening, unload and reload all your instruments and the glitch should disappear.
StudioJ, that was a fix for one of the problems, but I don\'t think it will fix my problem. I will try it, but considering it is taking 10+ minutes to load all my instruments in I don\'t know if I can deal with waiting 20 minutes to get up and running each time.
The slow loading thing is really annoying. The first half of the instruments load really quickly and then the last half take about 8+ minutes. I am at the point where I am going to take the damn memory back out of my system and go back to using 512MB of memory because trying to use 1GB is just giving me tons of headaches.
There seems to be some misconception as to what the Min/MaxFileCache settings do and how they affect GS. Normally when a file is read off a disk, only the specific bytes that are requested by the program are loaded into memory. If you are reading a file straight through from the beginning to the end, the hard drive is working at maximum efficiency because the heads will seek the next data track in sequence. However, you rarely have just one program acting on one file at a time under Windows. Usually, several files are are being read from simultaneously, forcing the hard drive heads to seek all over the platters. This can be very inefficient. You can use a trick though to improve efficiency. Most of the time, an individual file is read sequentially -- that is, a program reads one chunk, then a little bit later reads another chunk that comes after that, and so on. If you can somehow \"preload\" that next chunk and save it in memory, you won\'t have to access the hard drive when you need the next chunk. Well, Windows does exactly that! When a chunk of a file is read, Windows \"guesses\" that the next chunk after that will be read as well, so it continues on past the first chunk and grabs the second chunk, saving it into memory. This memory is known as the file cache.
You would think that in most situations, the more cache you have, the better. And you\'d be right. With lots of cache, Windows can preload lots of chunks, making the reading of data off the hard drive very efficient. With GS though, you have hundreds, even thousands of chunks needing to be read for every instrument loaded. That means Windows will not only read the chunk GS wants to read, but also the chunk that follows. GS has its own caching scheme. It will read a chunk, and while it\'s playing back that first chunk, the second chunk will be loaded into memory from the hard drive. You can see how this situation can become very inefficent. GS will read a chunk and cache it, Windows will then cache the next one, GS plays back the first chunk and starts loading the second chunk into its own cache which Windows feeds from its cache, then loads up the chunk after that -- double the work for the same data!
Now here\'s where Min/MaxFileCache comes in. Windows will normally grab as much unused memory as it can to use as cache. When you start loading a GS file, Windows will see that many, many chunks are being read, so it starts caching. But since GS uses its own cache, it starts to gobble up the available memory. Windows sees this and starts resizing its cache so that GS can have more memory. When Windows does this, it also must move around the chunks in its cache, discarding some chunks and keeping others. You can see how this will lead to some horrible inefficiencies: GS makes a request to Windows to set aside a block of memory; Windows realizes there\'s no unused memory, so it resizes its cache to accomodate the request, moving some chunks around in the cache and discarding others; GS then loads that block of memory with a chunk of data from the disk; Windows feeds GS that chunk, then caches the next chunk from disk and discards some other chunk to fit it in; GS makes a request to Windows to set aside a block of memory . . . rinse, lather, repeat. This is why loading GS samples will start getting slower and slower as you fill up memory.
We can prevent the resizing of the cache by setting the MinFileCache and MaxFileCache to be the same value. Windows will allocate that specific amount and never change it. But what should that value be? Remember that GS has its own caching scheme. If GS is running on a dedicated machine, we would want to turn Windows caching off by setting that value to zero. This way, both GS and the hard drive operates at maximum efficiency. If you run GS and other programs on the same machine, having a Windows cache increases the efficiency of the other programs but decreases the efficiency of GS. So we must strike a balance. If you have a machine with 1 gigabyte of memory for instance and set MinMaxFileCache to the Microsoft recommended recommended 512MB, you automatically lose half the memory that GS can use, plus you also get that double buffering inefficiency described above. Do we really need to have a large cache size? Unless you are editing large graphic files or managing huge databases, the answer is no. Most applications don\'t have huge data files that they load big chunks from. A typical Windows machine can be very efficient with only 4MB to 32MB of cache. On my particular machine, the sweet spot seems to be 16MB. I have 1GB of memory, all my samples load speedily, and GS almost never pops or crackles when running my sequencer at the same time.
Thanks for the input, everybody. If this was Linux then at least I would have had some chance to understand what this cache is all about, but in Windows...
Anyway, I also found out that another thing that slows down the machine to an _enormous_ extent is having too much data in the \"My Documents\" directory. I used to record audio into that directory, but apparently that\'s the worst thing you can do. (It causes Explorer to take up to 30 seconds for navigating from one directory to another.)
Only Microsoft knows why...
Did anyone figure out a solution to the slow loading problem? I would love to load and unload and reload the instruments to try and get rid of the 2 minute problem, but it is currently taking up to 10 minutes to load all my instruments.
My productivity with Gigastudio has dropped to almost zero, and Tascam tech support appears to be out to lunch, which is really too bad seeing the excellent service I got from Nemesys before. I am getting royally frustrated.
[This message has been edited by Jamieh (edited 10-29-2001).]