The Resource Monitor shows detailed real time disk activity, where you can clearly see when T is accessing audio files and when the page file is being accessed.chico.co.uk wrote:"I use the W7 Resource Monitor to examine disk I/O, which reveals that the issue can present itself with T audio buffering happening, or not."
I don't think I understand what you mean by this. How can you tell whether T audio buffering is happening from Resource Monitor?
I'm also curious about mixed sample rate performance in T. This includes how things like convolution reverb impulses that are of a different sample rate than the audio files being processed in T are dealt with. I've made comment in this thread regarding issues I'm having with SIR2 running 44.1 impulses against my 88.2 audio. If SIR is in a rack, the live mix sounds great, yet the render has the verb wrong. Removing SIR from the rack fixes the render.I don't have any answers to this really, but I'd probably get some disk utility and run it to check the read and write and random access speeds for the disks you use, and check you can actually read and write the kind of iops you're trying to achieve at the samplerate you're using
I'd also maybe check whether all the audio (recorded tracks and any samples, or audio sounds used in plugins) are at the same samplerate and bit depth you're using in your soundcard. Just because I'd want to rule out some kind of resampling taking place in either the app or by the audio driver, to play back everything in the edit. As in, if you're using 16bit 44khz samples on one track, but recording audio at 88khz, and the card is running at 88khz, does the sample get converted on the fly, when the audio first gets played? I dunno, but if you're looking for things to rule out, maybe that's an idea...
I also wonder if the implementation of the new Elastique Pro engine in T has issues to work out. I typically record in 88.2 / 24 and use the Elastique pitch correction and time stretching quite a bit.
I've most certainly spent an great amount of time with DPC, which smoked out driver issues and such. Latency Monitor was also used for tuning. My system checks out very well with these various tools. While we're on the topic of system tuning, I will say that one gotcha app that I found to really mess with T is the Cubby cloud backup process. I was not aiming that app at any audio space, thus it wasn't that sort of sharing conflict, yet when I disabled it, the Tracktion.exe process CPU consumption was cut by more than 50%. Another issue I just posted to this thread concerns SpeedStep issues with my laptop overheating without knowing it was occurring. That was my most niggly discovery, which happily resolved my T CPU clock throttling issue. Search for it and read if you care to.Did you look for DPC issues yet? I spent ages chasing them on an old laptop that finally died a death, but they seemed to be causing me grief, at one point...
