Thanks Peter for your very informative reply! I am just very excited
about dual processor support in Vegas and the fact that dual processor
Celeron boxes are within financial reach.

Since I already have the box built, I think I'll toss in the Yamaha
DSP Factory and see what that does.

Thanks too for the explanation of how Vegas handles audio hardware.

Great product!

Bill

Peter Haller wrote:
>>
>>The problem with any benchmarks or measurements like this is that it
>>is for a single scenerio. Because of the way Vegas is architectured,
>>you can change the perfomance you get by altering the way the audio
>>is routed/processed. This makes benchmarking Dual CPU performance
>>difficult and in most cases meaningless.
>>
>>The scenero you describe looks like a single bus with a single audio
>>card for i/o. The big limit on this scenerio would be disk
throughput
>>as this is the part you are stressing.
>>
>>When you add additional hardware devices - i.e a multiport device -
>>and set up multiple main busses, you increase the number of threads
>>that run. For every hardware port/device used there is at least one
>>thread created. This threading is then use as the context for
>>"mixing" all audio assigned to that bus. If you have 20 tracks all
>>assigned to the same main bus, your through put should be about the
>>same as if you had a single bus, though there would be a bit more
>>overhead as the other busses are active and must still be serviced
so
>>that you can change track/fx routing assignments on the fly. (This
is
>>a very simplistic description of what is going on in Vegas, but
>>should give users and idea of where resources are being utilized.)
>>
>>
>>Disk i/o is typically the bottle neck as this is the weakest/slowest
>>link in the chain. NT's async file i/o helps with this and appears
to
>>consitently out perform Win9X with or without SMP under NT. (I would
>>be keenly interested in anybody using striped disk set ups - whether
>>NTFS software based or hardware supported. This should remove some
of
>>the the disk i/o bottle neck and really allow the track count to
>>increase.)
>>
>>20 _solid_ tracks is a lot. Don't think I have ever had that many in
>>any of my projects. Sure, lots of tracks, but not all solid audio.
>>
>>A track measurement when there is no overlapped i/o is rather
>>misleading. 32 tracks with only 10 tracks having content at the same
>>time is not the same as 32 tracks of solid streaming audio.
>>
>>If your media is of different type - i.e. mixed sample rate/bit
>>depth, mono/stereo, MP3 (why?) - you will get different performance
>>and track counts as all of this adds into CPU usage - converting
from
>>a 44.1/16 raw file to say 96/24 takes CPU work(resampling). Things
>>like this will effect the number of solid audio tracks you can
stream
>>at one time. (IMHO working with MP3 files is silly as this is _alot_
>>of work and you are working with lower quality audio. But hey, we
>>allow it and many find this feature very useful.)
>>
>>My point in all of this is that performance benchmarks are different
>>based upon the mixer/routing setup, Assignable FX routing. media
>>types as well as driver and disk related issues.
>>
>>Peter
>>
>>
>>
>>William Boggs wrote:
>>>>I did some informal, non scientific tests for anyone who is
>>>>interested.
>>>>
>>>>System: ABIT BP6, Dual 466 MHz Celerons, 128 Megs, 7,200 RPM
>>>>UDMA 33 (9.5ms access), SB AWE64 Value
>>>>
>>>>WinNT 4.0 SP5: 21 mono tracks w/EQ + Comp on every track
>>>>
>>>>Win200Pro 2072: 32 mono tracks w/EQ + Comp on every track
>>>>
>>>>Would SF or anyone else care to post their results for
>>>>comparison?
>>>>
>>>>PS: Too early in the game for the UDMA 66. As far as I know,
>>>>there are no drivers yet for NT or 2000 :(