Bristol_Jonesey


.... 

........

If these settings are all normal, then is it down to the RAM?

Hi Jon,

Due to the BSOD, I'd test your system's RAM and stress-test the system as a whole.
If you've got a bad stick of RAM... or a hardware issue, Sonar X1 (or any other DAW app) is going to have problems.

As was suggested, check your DPC latency.  If there are large spikes, that's guaranteed to cause glitches/dropouts.
If your idle DPC latency isn't low/consistent, you'll have to run the Emu at larger ASIO buffer sizes.
If there are spikes well into the yellow/red, those will need to be addressed before you can effectively work.

Also, check to make sure all HDs are running in DMA mode.  If one slipped into PIO mode, that'll absolutely kill performance.

Another thing to check:  Make sure the Emu is connected to a USB 2.0 controller (not a 3.0 controller).
Most USB 3.0 controllers are provided via 3rd-party add-on controllers (not integrated into the motherboard's chipset).  Using these controllers can result in poor performance... (similar to using a "rogue" chipset Firewire controller with a Firewire audio interface)

Thanks for the tips. The latency seems to be fine and the IDE ATA/ATAPI controllers running in DMA mode, so it's not that. The E-MU is connected to the computer directly which is 2.0 so that is fine. I will check my systems RAM now and see if that is the problem

You might open Task Manager in Windows, go to Performance Tab, start the project, and watch your CPU and memory usuage.

I had this problem on a project that was using Hollywood Strings.  CPU usuage would go up to 100% and the noise began.  Solo isn't a true test because it turns off a lot of processing demand.

I had to solve this by (1) making a copy of the project under a different name, (2) deleting everything but Hollywood, (3) bouncing to audio, and (4) pasting the audio back into the original project.  I saved the original project with the audio under yet another name, and deleted the original Hollywood tracks, keeping only the imported audio.  Never lose your original source tracks!   I'm sure you know that. 

This could happen with any virtual instrument or set of instruments.  In my case, my PC was always able to handle things until this project in which Hollywood took it over the top.

If you don't have a ton of tracks or any high-demand VIs, then this isn't it.
 
Is that you and your band in the picture?  You had a lot of soft synths on Penny Lane.

Ok the CPU reaches about 75% maximum during playback, so I don't think that's the problem, unless that is too high?

Yeah in fact it is quite an old picture of us, we are only just getting to grips with this new technology......


EDIT: I don't believe that method will affect anything as someone previously said, z3ta+ 1 and session drummer 3 do not use up a lot of CPU.

75% is pushing it...

That is high.

So how can I dramatically lower it? I have already tried simple methods that are meant to lower it, but they don't seem to be making any difference.

Hopefully Mr Roseberry will be back to guide you further on this.

JonBoh


So how can I dramatically lower it? I have already tried simple methods that are meant to lower it, but they don't seem to be making any difference.

Bounce/Freeze often. Audio tracks themselves don't consume a lot of resources but the plugins sure do, especially when you have multiple synths and multiple effects active/open in a project. I would agree with others here that 75% is pushing the limit in terms of CPU use. For tracking, especially with softsynths - use as few active tracks as you need, then for mixing - bounce and work with the audio tracks themselves rather than the instrument tracks containing the softsynths and plugs, all of which consume resources. Develop a workflow that works for you according to your preferences and system limitations.
Also I think increasing your RAM would make a significant improvement for a low investment.