It sounds like the issue may be specific to 32-bit. One thing I can think of on the aud.ini change suggestion is that, if I remember correctly, some of the T-RackS plug-ins, including this one, have a fair bit of latency (I seem to remember a few latency compensation issues a long time back when I was using these more extensively, possibly when I was still on the 32-bit version of SONAR 8). Perhaps the suggestion your friend made relates to some tradeoff between system timing considerations and giving the plug-in enough time to "do its thing". I don't see a "buffers" parameter in AUD.INI, but I do see an ExtraPluginBufs, which the manual describes as follows:
It instructs SONAR to set aside extra audio data buffers, to accommodate plug-ins which do large amount of internal buffering and therefore "keep" data buffers to themselves. Recommended maximum setting of 64 or 128.
Perhaps this is what was intended? Mine is set to 0, but I'm running 64-bit and my computer is likely much slower than yours (I'm on a Core 2 Duo E6600), and I believe this sort of stuff is specifically for tuning things that may be affected by system performance. This is totally wild speculation, but perhaps some improvements in the efficiency of SONAR's audio engine from X1 to X2 resulted in your system's just being "too fast" for the internal buffering this plug-in needs to do to keep up. Can't hurt to try it out, in any case, since the worst that could happen is it makes things worse and then you have to change it back and you're back where you started.
Good luck.
Rick