Problems during recording


Studio 1784
My set up -ASUS Lap top X200CA, 8 gig Ram/ External Hard drive- 1 TB/Windows 8.1/ 256gb SSD/ Focusrite Scarlett 2i2 USB Audio Interface/ Rode Mic/ M-Audio 8” 3 way monitors/ Semheiser HD Pro closed back headphone/ Voice Tone Harmony- G-XT/Music Software- Sonar power studio 6 / Editing software Sound Forge 10.

When I record vocals my program Sonar Power Studio 6 skips and sometimes stop during recording and dropout. Can anyone please help me correct this problem. Thanks!!
Last edited:
Was it working fine on the exact same setup before and suddenly started doing this?
As a guess I woud suspect latency issues. You could try raising your latency settings. Or perhaps you are using a plugin that is hogging your processing power.

If you have plugins in the project, try turning them off one at a time and if any of them fixes the problem.
Does it do it on every project? Did you try disabling plugins?

Obviously your gear is capable of recording, since you say the problem just started. So you need to figure out what's changed.

You need to start eliminating culprits. If it's happening on just one project, I'd suspect a plugin. If all projects, the pn something in the OS or drivers, etc.
When bad things happen, to identify a cause, you need to minimise the range of possibilities.

So, do obvious and simple things:

1 reboot
2 start with a fresh project. Record just one short track.
3 don't use any effects

and so on.

If simple works . . . add complexity . . . more tracks, more effects.

If simple doesn't work, then you have at least eliminated effects and tracks
The primary reason I asked if it just started, is your symptoms could be the result of an underlying failing hardware component. If your computer has a diagnostic partition boot to that and have it run a hardware check. Hard drives, system memory, power supplies, and sometimes capacitors on motherboards can all fail over the lifetime of a computer. You could chase your tail for months thinking it's a software issue when it was something under the hood the whole time. You could also run a stress test (there's free ones you can find online) in an attempt to root out the cause.

If nothing's changed but perhaps you applied a windows update recently at which time the problems started, you could try a system restore to the point just before problems started to occur. Make sure you have all your important data backed up somewhere just in case the restore fails. This is a drastic step IMO and should only be done once everything else is eliminated. System restore can toast a Windows install if it fails. It usually doesn't, but as a long time computer tech/engineer, I get to see when it does. Not pretty. lol
The symptoms he's describing sound like an audio dropout. While I certainly wouldn't rule anything out at this point, in my experience this is caused by something draining the processing power. Usually an errant plugin, or too many tracks, or too many effects, etc. Could also be a bad memory chip, or a hard drive starting to go, or an updated driver causing hiccups in your audio hardware, but I'd expect those to show in other areas beside Sonar.

Gecko has the right approach. Strip things down, and rebuild one by one. If you can't record even one track, without effects, then start looking outside the program.
Diagnostic tests, at least on OE machines that include them into the build, are easy to run and eliminate something that could save a lot of time wasted chasing ones tail thinking it's a software problem. It's really the first thing that should be explored in most "was working fine yesterday" situations (with no other smoking-gun symptoms) since it's a time saver and not something you have to actively do (just start the diagnostic, come back in 30-45 minutes).

I've seen plenty of seemingly odd and specific software based symptoms end up being hardware. In this case, music production is probably the most demanding task the computer accomplishes, so it would seem reasonable to think it would also be the time at which a computer would start to reveal an underlying issue not seen doing more benign/casual/less processing intensive tasks.