Why would you ever have latency problems when rendering?

[chrishurley]

I've read with much concern various messages indicating pops and other defects in the resulting files after a render. I could be completely wrong, but it seems that some of the suggestions included doing subrenders or increasing the ASIO buffers.

For a render (i.e. mixdown) why would this ever be a problem? For realtime playback, I can understand, but for a non-audible render-to-file, why would Tracktion not simply take however much CPU time it needed (even dipping below realtime if necessary) for the task?

There is even a checkbox to force it to render in real-time and I find myself wondering why you would ever do that, unless some plugin reacted based on real time instead of the number of samples it receives as compared to the sample rate it is expecting.

Anyone have any insight on why rendering seems to do anything other than work 100% properly all the time? :)

[djsubject]

i find the letest T2 relese to work fine with rendering

the release before that was a different story

in this release i have found all renders to be perfict

unless my pc needs a defrag, in witch case i get the odd pop here & there

Subz

[kenjkelly]

I agree. I wondered the same thing. If the app has all the time in the world, why would it pop?

The last rendering problems I had, I chased to using the Emu 1820m FX DSP VST to add (too?) many insert effects. I had thought that offloading effects to my Emu DSP would solve CPU load problem, so I used it heavily. I'm not sure if the bandwidth of the Emu DSP was overloaded or it had some interaction with the PCI bus. There is no way (no meter) to tell if the DSP is getting maxed out or missing datapackets. The result of overloading the DSP was stuttering and pops during rendering.

One other thing to consider: When mixing many tracks using the same "sends", the "send" VST would, theoretically, see the sum of all inputs sent to it, which could cause short pop-like clipping. For example two tracks being sent to a VST send should not exceed "-6db" PEAK each (-6db + -6db=0db). For three tracks it is -9db each, etc (correct me if I missed on the Db math). The -db number does not mean the track fader setting, it is the signal actually sent to the "send" pre or post fader.


If it is not any of those reasons then I don't know why either.

Ken

[chrishurley]

unless my pc needs a defrag, in witch case i get the odd pop here & there

Subz

It just doesn't make sense to me why that would bother a render- unless perhaps the target file format is different in a way that it creates an overload condition on some samples.

That would still seem to be a defect in the render process to me.

[djsubject]

i think it was due to the samples i was using being defragmented

Subz

[Lunch Money]

It still shouldn't matter. There's no 'time limit' on rendering. The processor simply doesn't move to the next step until the job it's currently doing is finished. It's all linear and not affected by the time domain at all. Er, supposedly. I don't know if that's actually the case.

In theory, let's pretend that you had a file SSOOOOOOoooo defragmented that it took a half-hour to sort out all the bits and pieces!!!

The end file still shouldn't have pops and clicks, it'll just take an extra half hour to "put together" due to your unearthly rate of [edit, was originally "DE-"] fragmentation.

Greg

[valley]

yup.

the only left-field case is silly plugins that decide to cut out when the CPU approaches 100%, which on any normal render it would do. But since you can't legislate against stupidity, NI are free to keep doing dozy-assed stuff like that and 1x render remains your friend.

[kenjkelly]

I can't do this test now because Tracktion isn't working right on my Pentiums D, Windows x64, Emu 1820m system:


We could test whether it is a VST or core problem by creating a song without any VSTs with tons of tracks to see if that has problems rendering. Then create a song with few tracks and tons of VSTs. (I don't remember Tracktion's limits on tracks or VSTs)

For those with hardware DSP FX, a test of loading only CPU based vs only DSP based VSTs would be interesting.

ken