Pops and clicks when recording

[TonyKeys]

Only when I am recording external audio into my computer, I get these pops and clicks. when I record internal sounds through midi it is fine. Im using the latest sonar and I also use FL and record into edison. I tried adjusting the buffer and still no luck. Im using an m-audio solo firewire as my input and my output sound. any troubleshooting ideas that I can try? can it be my m-audio solo? I just built my computer and now i have these issues, my older,slower computer worked fine so im a little confused why i'm having this issue.

[royjhu]

Originally Posted by TonyKeys

Only when I am recording external audio into my computer, I get these pops and clicks. when I record internal sounds through midi it is fine. Im using the latest sonar and I also use FL and record into edison. I tried adjusting the buffer and still no luck. Im using an m-audio solo firewire as my input and my output sound. any troubleshooting ideas that I can try? can it be my m-audio solo? I just built my computer and now i have these issues, my older,slower computer worked fine so im a little confused why i'm having this issue.

I had the same problem and it turned out my driver settings were screwed up. By default sonar sets to WDM/KS, when (at least for my setup) ASIO works better. If you haven't already tried to do so, try switching your Driver Mode to ASIO: Options -> Audio -> Advanced

[TonyKeys]

I will check my settings when i get home. Thanks for the tip.

[bitflipper]

Pops, clicks and dropouts are the audible manifestation of interruptions to the data stream.

When recording, the audio interface is filling a buffer with data that's pouring in at a rate of at least 44,100 values every second, faster if you're recording multiple tracks and/or at higher sample rates. That's a lot of data, and it's important that it not be interrupted, even briefly.

As soon as the buffer has been filled with data, the interface switches to another buffer and starts filling it. SONAR (or Cubase, or Logic, or Pro Tools or GarageBand) then begins to process the data dropped in there by the interface.

By the time the interface has filled the second buffer, SONAR must be ready to start draining it immediately. But if it still hasn't finished with the first buffer, then whatever unprocessed data remains in the buffer is tossed. The data stream is interrupted, and you get a click (if it's a small amount of data), a pop (if it's a larger amount) or the dreaded DROPOUT message indicating the problem is so bad that SONAR's not even going to try. (In the latter case, a "dropout" as notified by SONAR happens after 4 consecutive buffers are missed.)

So it all revolves around the CPU having sufficient time to process a buffer-full of data before the next buffer fills up. That's a finite amount of time, depending on the size of the buffer and the data rate (sample rate * number of channels). You can get a clue as to how the CPU is keeping up from the CPU meter in the status bar. If it reads 50%, that means the CPU required 50% of the allotted time to process the data (recording + playback). (The CPU meter is not an indicator of how much CPU SONAR is using, which is why it never agrees with Task Manager.)

So there is really only one reason for pops 'n clicks: the CPU has too much to do in between buffer pump cycles. You have to figure out why that is, and alleviate the load on the CPU so that it can keep up.

The easiest thing to do is increase the buffer size. That alone may give the CPU enough headroom. Sometimes, though, it's not enough.

The next-easiest thing is to think about the tasks you're making the CPU perform during recording and (more importantly) playback.

If you've got three vocal tracks and each one has an instance of Perfect Space on it, that's a lot of overhead that can be reduced by using a single instance of PS on a bus.

Any audio tracks that have effects on them are candidates for freezing. Freezing eliminates all the effects from the CPU load. Freezing soft synths gives an even better bang:buck ratio. Using a drum sampler like EZDrummer, Superior, BFD or Jamstix? Freeze those guys and chop your CPU usage waay down.

Bypass any mastering effects while tracking. Most mastering effects, including all of the bundled LP-64 effects, are serious CPU-eaters. Save these for after tracking, when you can freeze tracks and raise your buffers.

Sometimes, people do all these things and STILL have pops and clicks. At that point, you have to suspect something's amiss in your computer. Do not blame it on your DAW, do not blame it on your audio interface - they are rarely to blame. More likely suspects are your network adapter or your video adaptor.

Aarg, I didn't mean to write a book on the subject (Hmm, maybe I should...) and supper is calling my name. Hope this helps.

[cakewalkgg]

right when I got my new computer my pod xt couldnt play or record without pops and clicks.. although my fast track pro had no issues.. through painfull troubleshooting and research, Line 6 convinced me to buy a dedicated usb card. It eliminated ALL of the problems when recording and 99% on playback. I decided to live with the occasional playback click.. over the last year, the pod has had several driver updates.. and lo and behold.. now I never have a glitch at all..
Im thinking it was a little of both the line6 drivers and some the onboard usb chip

I dont know if this type of issue is possible with firewire chips.. but if you have a firewire card, you may try to avoid the onboard port if possible.

[TonyKeys]

Thanks for all the help everyone but ive tried it all, think. but still the same problem. Im thinking of one more thing that just came to me, maybe plugging in my m-audio using the external power, instead of having the firewire cable do everything. Does anybody think that might help? im going to try tonight. thanks for all the help again.

[bitflipper]

Originally Posted by TonyKeys

Thanks for all the help everyone but ive tried it all, think. but still the same problem. Im thinking of one more thing that just came to me, maybe plugging in my m-audio using the external power, instead of having the firewire cable do everything. Does anybody think that might help? im going to try tonight. thanks for all the help again.

Well, you obviously haven't tried everything, Tony, or you would have solved the problem Trust me, it's not a voodoo curse that can't be resolved.

It doesn't seem likely that plugging the wall-wart will help, but it won't hurt to try.

Have you checked your DPC latency? I thought I'd suggested that earlier, but I guess that was in a different thread. Download the DPC Latency Checker, run it and let us know your results.

Do you have a PCI video adapter? Run the PCI Latency tool and report back.

[TonyB]

Originally Posted by bitflipper

Pops, clicks and dropouts are the audible manifestation of interruptions to the data stream.

When recording, the audio interface is filling a buffer with data that's pouring in at a rate of at least 44,100 values every second, faster if you're recording multiple tracks and/or at higher sample rates. That's a lot of data, and it's important that it not be interrupted, even briefly.

As soon as the buffer has been filled with data, the interface switches to another buffer and starts filling it. SONAR (or Cubase, or Logic, or Pro Tools or GarageBand) then begins to process the data dropped in there by the interface.

By the time the interface has filled the second buffer, SONAR must be ready to start draining it immediately. But if it still hasn't finished with the first buffer, then whatever unprocessed data remains in the buffer is tossed. The data stream is interrupted, and you get a click (if it's a small amount of data), a pop (if it's a larger amount) or the dreaded DROPOUT message indicating the problem is so bad that SONAR's not even going to try. (In the latter case, a "dropout" as notified by SONAR happens after 4 consecutive buffers are missed.)

So it all revolves around the CPU having sufficient time to process a buffer-full of data before the next buffer fills up. That's a finite amount of time, depending on the size of the buffer and the data rate (sample rate * number of channels). You can get a clue as to how the CPU is keeping up from the CPU meter in the status bar. If it reads 50%, that means the CPU required 50% of the allotted time to process the data (recording + playback). (The CPU meter is not an indicator of how much CPU SONAR is using, which is why it never agrees with Task Manager.)

So there is really only one reason for pops 'n clicks: the CPU has too much to do in between buffer pump cycles. You have to figure out why that is, and alleviate the load on the CPU so that it can keep up.

The easiest thing to do is increase the buffer size. That alone may give the CPU enough headroom. Sometimes, though, it's not enough.

The next-easiest thing is to think about the tasks you're making the CPU perform during recording and (more importantly) playback.

If you've got three vocal tracks and each one has an instance of Perfect Space on it, that's a lot of overhead that can be reduced by using a single instance of PS on a bus.

Any audio tracks that have effects on them are candidates for freezing. Freezing eliminates all the effects from the CPU load. Freezing soft synths gives an even better bang:buck ratio. Using a drum sampler like EZDrummer, Superior, BFD or Jamstix? Freeze those guys and chop your CPU usage waay down.

Bypass any mastering effects while tracking. Most mastering effects, including all of the bundled LP-64 effects, are serious CPU-eaters. Save these for after tracking, when you can freeze tracks and raise your buffers.

Sometimes, people do all these things and STILL have pops and clicks. At that point, you have to suspect something's amiss in your computer. Do not blame it on your DAW, do not blame it on your audio interface - they are rarely to blame. More likely suspects are your network adapter or your video adaptor.

Aarg, I didn't mean to write a book on the subject (Hmm, maybe I should...) and supper is calling my name. Hope this helps.

I love it! I thought I was back in one of my EE classes!

That's the best explanation I've heard on buffer operations in DAW system.

[TonyKeys]

I attached my screenshots for you to see my results. sorry for the late response.

[bitflipper]

The dpc screenshot shows a well-performing system, with latencies well into the green. However, did you take this picture while experiencing pops and clicks? If a network or video adapter were only intermittently causing large dpc spikes, you might have to get lucky to catch them in the act.

The pci picture would seem to vindicate your video card as the culprit, since the only device with a specified pci latency value is the firewire adapter. This might seem OK, given the importance of firewire to your setup. However, it's possible the adapter is actually consuming more pci bandwidth than needed to service the audio interface. It's a VIA chipset, which should be OK but some interfaces famously want to talk to an interface with a TI chipset. I don't know if yours is one of them, but it might be worth substituting the firewire adapter and see if it makes a difference.

The cpu snapshot shows a largish spike - what was happening right then? Were you starting up your DAW? Or recording? As with the dpc latency tool, the trick is to catch the pops and clicks in the act, and look at the Processes tab rather than the Performance tab. It's useful to know if the pops/clicks coincide with a CPU spike, but we won't know which process is eating the CPU without looking at the Processes tab. (Tip: click on the "CPU" column heading to sort entries by CPU usage.)

You're definitely on the right track for solving the popclick mystery. You just need to get those screenshots while the problem is occurring.