Simon Ravn
06-26-2002, 07:11 PM
We were discussing this, Thomas J, Maarten and I on the IRC #MIDI-Mockup (Efnet, be sure to drop by:)) channel tonight. I was talking about getting MSG32 crashes like so many others. I notice this happens when GS is really getting stressed and beginning to have weird note dropouts and hickups.
It is not a CPU problem. When GS does 160 voices it uses about 40% CPU. It is not a HD TRANSFER problem, new Barracuda IV harddrives, UDMA 100. It is not a PCI bandwidth problem, using the SiS chipset which has the best PCI bandwidth.
So what is it? Well our conclusion, and pardon me if I am naive that we have found a reason which nobody else seems to have thought of, was that it boils down to HD seektime. If your HD, in addition to streaming the data to RAM, has to find 80 different locations on one drive (or two, in my case), it will use at LEAST 10 ms on each seek - probably more, because the samples are spread out across the drive(s) - which amounts to 800 ms. of seektime per buffer it has to read. I am not sure how big the buffers GS reads are, but I think somewhere around 32k or 64k - which is less than a second of data. So each second 800ms will have to be used on seeking alone, leaving 200ms. for the actual reading.
Maybe I am not taking some things into consideration here, but if I am not far off, this should make it impossible to read 160 unique voices. If you use sample repetitions across channels or use the same short samples many times, this will be less of a problem, since the data will be cached in the VCache (or where else), which is also why, in SOME performances I have no problem getting 160 voices all the time, whereas in others I begin getting into trouble and crashes around 140-160 voices.
Does anyone have a view on this subject?
It is not a CPU problem. When GS does 160 voices it uses about 40% CPU. It is not a HD TRANSFER problem, new Barracuda IV harddrives, UDMA 100. It is not a PCI bandwidth problem, using the SiS chipset which has the best PCI bandwidth.
So what is it? Well our conclusion, and pardon me if I am naive that we have found a reason which nobody else seems to have thought of, was that it boils down to HD seektime. If your HD, in addition to streaming the data to RAM, has to find 80 different locations on one drive (or two, in my case), it will use at LEAST 10 ms on each seek - probably more, because the samples are spread out across the drive(s) - which amounts to 800 ms. of seektime per buffer it has to read. I am not sure how big the buffers GS reads are, but I think somewhere around 32k or 64k - which is less than a second of data. So each second 800ms will have to be used on seeking alone, leaving 200ms. for the actual reading.
Maybe I am not taking some things into consideration here, but if I am not far off, this should make it impossible to read 160 unique voices. If you use sample repetitions across channels or use the same short samples many times, this will be less of a problem, since the data will be cached in the VCache (or where else), which is also why, in SOME performances I have no problem getting 160 voices all the time, whereas in others I begin getting into trouble and crashes around 140-160 voices.
Does anyone have a view on this subject?