I\'m running into pops and clicks when I start hitting 55-60 voices. At first I suspected my audio card (wami rack), but now I\'m starting to think that my drive just simply isn\'t capable of playing back that many voices. How many voices should I be expecting from GigaStudio with a 600Mhz P3 and a single IBM Deskstar UDMA/66 7200 RPM drive? Would popping and clicking be a symptom of the drive not being able to keep up?
Whatever the source of your difficulty, it\'s not a limitation of the IBM drive. I have this same Deskstar model installed as my GigaStudio library drives on two dedicated GigaStudio computers. These computers deliver about 110 voices of polyphony using a PIII 500 and about 126 using a PIII 700. One computer uses an Aark 20/20 card and the other uses a WaveCenter/PCI.
If you can\'t get more than 126 voices from a P3 700 I\'m really disappointed in Gigastudio. It can\'t be true that Nemesys are targetting the product at a 1Ghz PC that isn\'t out yet. Besides, I could get 64 voices easily with a 300mhz Celeron a, so if I can\'t hit 160 voices with my P3 700 I\'ll be disappointed. I certainly hope you find a solution, and if you do, please share your tips for getting more polyphony in this forum.
Yes, I\'m running separate drives for applications and GigaStudio libraries. Simon, for maximum polyphony count from a PIII 700 (or any other processor) it appears your mileage may vary. My voice count may go up after the computers have been optimized. I\'ve been too busy to bother and, besides, 126 voices hasn\'t been a particular limiting factor since I\'m getting that from each of the two dedicated GigaStudio computers. I\'ll bother to optimize later.
I have spent some time thinking about this, maybe the following helps:
Asuming that DMA is in use, polyphony depends on the one hand on hard drive seek time, and on the other on CPU power. (Well, in theory. Then you have the flipside of the coin, which is contention of various devices on the PCI bus. The new bus architecture of the i820 should go a long way towards fixing this - if only the chipset were actually feasible )
If you get clicks when the CPU still has headroom left (like at around 50%), the problem is probably due to seek time.
I\'ve noticed an odd thing which may answer this question; maybe some of you have some comments on this:
What I did was to use Sisoft Sandra to benchmark my ata66 drives (one of which is an IBM deskstar 27Gb). I discovered the following:
When plugged into my on-board IDE controller, Sandra gives an estimated seek/access time of 5ms (which is about right for beginnig of first partition).
However, when using a plug-in IDE ATA66 controller (in my case an Iwill using the Highpoint HPT366 chipset, with latest drivers, etc.), the seek / access estimate went up to 33ms!
Although the sustained transfer rate did not go down, I believe this increase in seek time is *bad news*. Reason is, Sandra gives another benchmark which is *random block read throughput* (i.e. the throughput you get when the head is jumping accross the disk to read various blocks), and I reckon this is the important parameter.
Whereas sustained transfer rate may be around 22MB/s, the random block read clocked in at 8MB/s for the 5ms seek time, and around 1.5MB/s for the 33ms seek time... The lower the seek time, the higher the random block read rates, because that throughput basically depends on an average of how long it takes to get to the data and to read it.
What Giga does, basically seems to approximate random block reads (I reckon it reads, in circular fashion, a block for each separate voice currently playing) Thus, the latter benchmark probably gives the best idea of how many voices to expect. I.e., each (mono) voice requires 44.1 * 2 kB/s (say).
On my system, for the estimated random block read throughput of 8MB/s, this figures as:
8 * 1024 / 88.2 = 92 voices. I seem to get around 110 voices before slight clicks set in - the difference probably owing to the fact that the GSt accesses aren\'t *completely* random, but follow a pattern. (And because benchmarking only approximates the real scenario.) This is on an 800MHz P3, 256Meg Ram.
So, the motto seems to be:
a) to increase polyphony, increase the random block read throughput
Some ways to do this are:
i) go for lower seek times, e.g. use first partitions, SCSI, etc.
ii) Spread your Gigs over multiple drives so that GSt can access them simultaneously (haven\'t tried this personally; comments?). In this case, make sure that each IDE drive is on its own separate channel (i.e. no master/slave setups). Also, I reckon you would then not see increased polyphony if you are only playing instruments whose gigs are stored on one of the drives.
b) It also seems to be wise to stay away from PCI add-on IDE controllers... I did not actually see what happens if I run my Gigs via that plug in controller - by the time I had done all the benchmarks, I was so sick of swapping cables and rebooting, that I decided not to bother
Hehehe, well, the BIOS on my add-in controller just caved in, so I had to move my CD drive to the onboard IDE, which meant I had to put my two 66 drives on one cable (i.e. like master/slave type thing).
Polyphony has now dropped to about 74 voices before clicking. (Weird, since I am not aware that anything is accessing my non-Gigs drive, so the gigs drive should get the whole channel to itself.)
That is odd. I\'m not going to be much help to you because I\'m also running the drives on separate channels - the programs drive and the CD-ROM are master/slave on the primary IDE, the library drive is master on the secondary IDE.