I finally found my system's limit

[QuikDraw]

I have a session that I’m working on that finally convinced me of the value of a Pro Tools Hardware Profile. I finally ran out of CPU power. Too many plug-ins. Any session with fewer plug-ins, actually I think, fewer D-Verbs than this works with my normal, nothing disabled, profile.

The session contains 16 audio tracks. All 16 tracks are bussed to 15 & 16, 13 tracks are bussed to 5 & 6 with input volume automation, 5 tracks are bussed to 3 & 4, and 3 tracks are bussed to 9 & 10. Each of those bus pairs are returned through a stereo aux-in, and each of the 4 auxes have plug-ins on them, and are volume automated.

I am running the following plug-ins: (all are the included DigiRack RTAS plug-ins)

3 Stereo D-Verbs
1 Stereo Slap Delay
2 Stereo Short Delays
1 Stereo Limiter
1 Stereo Compressor
1 Mono Compressor
1 Mono De-Esser
11 Mono 1 Band EQs

Please note that I have many other sessions that are similar to this one in track count, auxes, automation, and plug-ins with the exception of one fewer D-Verb. Some sessions have even more audio tracks than this one and a few with MIDI tracks as well. None of them need a separate hardware profile except this one with 3 D-Verbs on it. Some of my sessions have even more plug-ins than this one and work fine. Still, only 2 D-Verbs on the sessions that work in my original hardware profile. I usually use more EQing than on this session, and sometimes more dynamic processing too. No need for a hardware profile until I need that third D-Verb.

The above describes the limit of what my system is capable. Even with the hardware profile I cannot add more plug-ins to the session. Well, I could get away with a couple more EQs, but I don’t need them on this song.

Here’s my system:

Asus P3B-F - BIOS Rev 1006 - 440BX chipset
Intel PIII 650 Slot 1 - 100MHz FSB
256Mb PC-100 SDRAM
ATI All-in-Wonder 128 AGP 16Mb (Driver ver. 4.11.6263)
I/O Magic (Promise chipset) ATA 66 PCI controller (in PCI slot #1)
Sound Blaster Live! Value (in PCI slot #2)
Creative PCI Flash 56 Voice Modem (in PCI slot #3)
Digi 001 (in PCI slot #5)
Maxtor 9 2041U4 ATA 66 20Gb 5400 RPM system drive (alone on CH-1 of ATA66 controller)
Maxtor 5 2049U4 ATA 66 20Gb 7200 RPM audio drive (alone on CH-2 of ATA66 controller)
HP 9100i CD-RW (alone on CH-1 of motherboard ATA33 controller)
Toshiba SD-M1212 DVD ROM (master on CH-2 of motherboard ATA33 controller)
Iomega Zip 250 (slave on CH-2 of motherboard ATA33 controller)
Sony 3.5" floppy drive
Many fans blowing in all the right places
350 Watt double fan power supply

Please understand, I am not complaining about anything here. I am more than thrilled with Pro Tools LE and Digi 001. I am quite happy with the way my system runs Pro Tools LE as well. I am simply providing some information as to what a specific hardware configuration is capable of. I’m not really interested in any of the systematic tests where a certain number of specific plug-ins are used until the system finally gives up. This is a real-world test. This is a real session with real sonic needs that have been satisfied, but also brought my system to it’s knees (but it managed to crawl through it anyway!)

I hope this information is useful.

Mike

[Xman]

Hi... My experience is that every single D-Verb "eats" up like a 100Mhz processorpower... Should be intresting to see if the New RealVerb from Kind of Loud goes easier on the processor... Anyway I'm satisfied - this is my limits:
PIII 800eb
Asus CUSL2
256Mb 133Mhz Cas3(the badest) RAM
13Gb ATA66 ,46 Gb ATA100 drives

24 channel 44.1Khz 24bit
24 4-band eq's
16-18 compressors
Some Dessers
7-8 Delays
24 limiters
Some various extra 1-band eq's
A lot of automation
this with out any problem...
Then after 'bout 6-7 different D-Verbs the HW buffer error is on it's way...
(Note that this is on the 128 samples buffer...)
Nothing to complain about!

[QuikDraw]

Mine is set for 85% CPU usage. Also 1024 buffer when I'm mixing this session.

Still pretty respectable for a 650MHz machine running 3 D-Verbs though don't you think?

I should have a faster processor soon. When I get it I'll post new results with this session.

Mike

[Digi Engineering]

It's great for a 650MHz. Didn't mean to imply otherwise!

Eric Day
Digidesign

[Digi Engineering]

Mike & Xman,

What do you guys have your CPU usage limit set to (in Setups|Hardware)? Make sure it's at 85% for maximum plugin capacity (and lowest screen redraw performance).

Eric Day
Digidesign

[QuikDraw]

Just an update. I just upgraded my audio hard drive to a 60Gb drive! I didn't even know they made 'em that big! It's a Maxtor 5 T060H6 model, EIDE ATA 100 7200 RPM. My Promise ATA 66 controller has worked so flawlessly that I didn't have the heart to change it out for the free ATA 100 controller that was packaged with the new drive. So it's running at ATA 66 spec.

I also got an additional 128Mb of PC 100 SDRAM, for a new total of 384Mb.

My conclusions regarding these changes to my system? I couldn't live without the extra space, so the drive upgrade was a must! I just had an extra $60 burning a hole in my pocket, so I threw in the SDRAM for no good reason. If anything, the system is slower than it was before. If it is slower, it is barely noticable. All my sessions still work as before, and I still need a separate hardware profile for the session that started this thread in the first place. I say it might be slower than before because there is now another session, a much less demanding session, that also requires the use of a separate hardware profile when it did not prior to the upgrade.

I expected that the extra RAM would either give me more plug-ins, or faster response. Neither is the case. I can run 384Mb, or take out a stick and run 256Mb and see absolutely no change in speed or capability. I have run with less RAM and seen a difference below 256Mb.

Big hard drive - good! More than 256Mb RAM - Waste of money!

Pro Tools - Awesome!

Mike

PS. A faster processor is soon to be added. More results to follow...

[This message has been edited by QuikDraw (edited February 07, 2001).]

[Ruben]

Just remember that when you add memory, you must defrag you system drive; the swap file size is related to the amount of memory you have, so when you add memory, need to make room to the swap file to become bigger - surge windows will try to do it bigger - but it is a good practice to have that file contiguous (sorry for my English!) so it can swap it up faster, and by consequence getting a much better performance!

[QuikDraw]

Ruben,

That may be true if you have a swap file. I do not. Why in the heck would anyone need a swap file with 384Mb RAM? It also might be true when allowing Windows to manage the virtual memory settings, which I do not. I never have. I've always set the minimum and maximum size the same, usually 256, and usually set it on a different partition than Windows. This keeps the file contiguous, non-fragmented, and out of the way of Windows.

Besides, Pro Tools makes no use of the Windows Swap file, so it would have no bearing whatsoever on performance in Pro Tools. I turned off virtual memory when I was installing the new hard drive, and forgot to turn it back on. If I find that I need it, I'll turn it back on again.

Thanks though for your input. That's what the DUC is all about.

Mike

[Jopry]

QuikDraw:

ProTools may not use a swap file, but Win 9x does and usually works the best with the OS controlling the size (this tends to hold true even on NT). If you just prefer to not let windows control the swap size, you should try several different size settings and test speed difference. Also, you may want to check on technet to get more info on this. Slow OS = Slow ProTools. A swapfile to big or to small will slow the os considerably. Just a thought.
Happy Tracking,
Jared

[QuikDraw]

So far as I know, Windows only makes use of the swap file when it runs low or out of physical RAM. How big or small it is is determined by how much multitasking you do, and how much physical RAM you have. Whether you do it, or Windows does it, a decision is made that the swap file needs to be a certain size for optimum performance.

If you allow Windows to manage the swap file, it will change size from time to time. This causes fragmentation. Fragmentation, especially in the swap file, will slow a system down. By managing my own swap file size, and setting the min and max size the same, I've created a static file. It will not change size, and it will not become fragmented. The size I chose of 256Mb was based on two things. 1) I read it in a magazine once recently. 2) It always works well when I set it up that way.

I choose not to test various swap file sizes because I have no real measuring system to be able to say one set up is faster than another. Also, I've never noticed a difference in system performance based on changes to the swap file. For better or worse, I've never noticed any difference whatsoever.

So if there's no difference in performance, why bother messing with it? Because it reduces disk fragmentation. That's it. That's the only benefit. But that's why I do it. If you defrag as often as you should, that's where you'll see the system perform. A defrag that takes a long time when a swap file gets fragmented, is very quick when the swap file is contiguous.

That's just the way I like to do it. Also, I always uncheck "Rearrange my files so programs start faster". Oh, what a joke that is! Waste an hour or so a week defragging in order to save a second or two every time you open one or two optimized programs! What a joke. If you leave that option checked, what you're actually doing is creating fragmentation. And the defragger always has to move lots of clusters around. A waste of time. I don't want to spend an hour or more defragging to save 10 seconds a week opening a program.



Mike