What is killing my real time performance?

musman wrote on 10/11/2004, 12:36 AM
Just finished the rought draft of a short film and have found I'm getting basically zero real time performance and even selectively prerendering the material still looks choppy and the audio clips and slows down.
I'm using a p4 2.4gig workstation with 1 gig ram and 200 gigs storage from a removable 'data bridge' drawer and another 160 gigs from an acom firewire external drive.
I thik the problem stems from the number of tracks I'm using on the project- around 4 video tracks and 46 audio tracks. "Why so many audio tracks?", you might ask. The film is about a guy watching television so there are a lot of different speakers and music to pass for the shows he's watching. I added a lot of audio fx to make the audio sound like it was coming from a tv, but the fx differ on each speaker or music, so I put each on a seperate track. This also helps organize things. But now it takes over 12 minutes to make an ac3 render of the audio in this 9 min film.
An editor friend the other day suggested the # of tracks i'm using is the problem. He showed me a project of his on fcp and it had very few tracks and no pics on the video- he said he just memorizes what's there. He said the no pics helps with performance, but that would drive me nuts. I just thought it didn't matter how many tracks you had in a project. With my 46 audio tracks a maximum of 4 are playing at the same time, so I figured I was dealing with 4 audio tracks for the sake of rendering time and real time performance. Am I wrong about that? If so, is there any other way of increasing my performance?
Sorry for the long post, but thanks for any help!

Comments

TheHappyFriar wrote on 10/11/2004, 6:15 AM
try rendering all the audio to a new track then soloing that audio track.

that would eliminate the "# of audio tracks" excuse. :)

farss wrote on 10/11/2004, 6:31 AM
Even if there's nothing there from what I've seen Vegas still needs to keep checking every sample time to determine there's nothing there which munches up a lot of CPU time. Still 46 tracks of audio isn't that many however are they all at native project sample rate and bit depth? Having to do those conversions on the fly would sure slow things down. I found just one track of audio at 16/32 when the project is 16/48 slowed me down so I rendered the audio to a new track and muted the old one, seemed to run a bit better then.
Other thing that munches CPU time is have scopes monitoring in real time.

Bob.
musman wrote on 10/11/2004, 1:54 PM
Thanks for the help. Just checked and all the music is 44.1 Hz whereas the speech is 48 Hz as is the project setting and the mixer. But, I just went back and made a song 48 Hz in sound forge and I still only get a few seconds of decent playback. Video preview is set to draft auto, but when I turn it off I am getting a decent audio preview. However, there are no fx added in the vast majority of the project- just film originated material transferred to minidvcam and captured in Vegas. My editor friend said that fcp has trouble with video that is captured in one long clip rather than batch captured into little clips. I hate batch capturing (and the extra expense of a deck) and have always relied upon Vegas' scene detection in the past, so I captured the whole tape before cutting it into smaller clips.
Could this be the problem?
TheHappyFriar wrote on 10/11/2004, 4:16 PM
Doubt it. On my AMD XP 1800 I had ~15 audio tracks, 6 video tracks, almost everything has some kind of trackFX/eventFX & only the video stuttered.

If everything is on 1 drive, they could be pretty far apart on the drive & the HD must keep searching the drive every time it plays back.

If everything is on different drives, it could be one drive is slower. I'd reccomend a defrag. :)
SonyEPM wrote on 10/11/2004, 5:04 PM
Maybe your project is simply too much for your system but I don't think so. This sounds like a throughput issue, likely 1394 related. Would it be possible to, a least for test purposes, to copy the project and media (not copy/trim) to an internal 7200rpm IDE drive, see if there's any difference? We'd like to rule out the "stalling" 1394 drive problem reported by many people over the years.

If you were willing to send me a 1394 drive with the entire project including all source media, I'd personally inspect it for you (and load up some extra goodies when I send your drive back). We'll pay for fedex- email me at Dr.dropoutATsonypictures.com if you want to do this.
wcoxe1 wrote on 10/11/2004, 7:13 PM
Take him up on it, man!
It is a REAL deal, and a priviledge to work with Dr. Dropout.
TheHappyFriar wrote on 10/12/2004, 5:14 AM
i wish i had a vegas problem so my drive could end up at Vegas HQ. :)
winrockpost wrote on 10/12/2004, 6:33 AM
Wow . Sony EPM , thats great customer service,, excellent offer to help a customer.
musman wrote on 10/12/2004, 2:42 PM
Sorry, I've been gone, but I defintely will take advantage of this offer once I get the project to a stopping point. Very cool! Of course I've been having the same performance with both the firewire and the data bridge hard drives. Perhaps my friend who reconfigured the system is to blame, but we shall find out.
johnmeyer wrote on 10/12/2004, 7:18 PM
I didn't see anything in your earlier posts that indicated you were working from an external 1394/Firewire drive. There is a patch from Microsoft that might solve your problem, although if Sony can get hold of your drive and duplicate the problem, that would be the best way to go.

Here's the link to the thread that discusses the patch:

Firewire 1394 Solutions