digital audio system has latency. It takes around a ms each for the A/D and D/A processes and almost all multichannel devices use a digital cue mixer (analog mixers would be prohibitively expensive for most interfaces). So even onboard cue mixing -- often inappropriately labeled as
latency.
For instance, when MOTU introduced their popular 828mkII, they properly labeled the onboard cue mixing as
latency. But when many of their competitors labeled their own near-zero digital cue mixing as
about latency. This is marketing lie is nearly universal among the makers and they all point to each other's prevarications as the justification. It's a sham an disgrace.
Except that by the 5-10 ms (and certainly by 15 ms or so), most musically critical listeners will begin to detect serious problems with timing mismatches in the monitoring. And there are reports of discomfort from some over as little as a 2 ms latency. These are very
amounts of time -- but they are right at the threshold of perception and it's not just absurd for the makers to call that
-- it might not be enough to bug you -- particularly if your POD's own latency doesn't bug you (for clean tones, it's probably around that latency; as more FX modules get brought into a patch preset, the latency goes
, not unexpectedly). So if your POD's delayed output doesn't bug you, the near-zero latency from an outboard device's onboard cue probably won't.
(I realize you're not in the market for such an unit right now. But since you're a little hazy on latency issues, I thought it was important to get some context.)
So using either near-zero onboard monitoring -- or outboard analog monitoring through a mixer if that's a problem -- should be fine for you as far as that goes.
But... what if you want to hear what you're tracking into your computer with?
You will start appreciating the timing efficiencies that the makers of a dedicated all in one device like your POD can build in -- since they know what all the performance variables out in front and can build a sort of
signal delivery efficiency into the device -- while a desktop PC, with its numerous subsystems from multiple parties and unknown performance characteristics must typically use a large amount of
for both data transmission to and from the hardware interface (hardware buffering) as well as (typically user-set) variable
buffers.
Monitoring buffers are typically the big hold-up. If you're not making your DAW do heavy lifting, such as convolution reverbs and fancy FX or having heavy live virtual synth playback while you are tracking, you can probably get away with minimal monitoring buffer size, possibly little more than that of the hardware buffer size. But if you've got a bunch of heavy duty plugs and v-synths going
-- you're going to find that you may have to increase that monitoring buffer so far that the delay between the live sound and the realtime-but-latent cue monitoring from the computer is noticeable, even so much as to give an 'echo effect.' (And when it gets
you have a problem. It's the not-quite noticeable stuff that gets into your tracks, subtly mucking up your player's timing when they overdub.)
Now, with regard to Cubase, Sonar, et al.
Who told you that? (Rhetorical. Don't answer.
)
'Cause, as much as I love Sonar (and I do, been using it since '97), it is
not as efficient as Cubase, as measured by the ability to carry a heavy load of plug ins with low latencies.
And Cubase is
not as efficient as Reaper.
(I'm speaking of Windows machines, here. I don't have any performance figures for Reaper on the Mac [Sonar is Win-only] but Cubase is
considerably less efficient on the Mac, presumably because of problems with the foundational architecture of OS X with regards to multithreaded communications within that OS's various cobbled together parts. The third party Mach kernel at the core of the OS was designed for modern, multiple, parallel messaging whereas the open source Darwin Layer 'above' it is an older paradigm, a monolithic system oriented to
serial messaging. The results appear to be ongoing problems for Macs when it comes to scaling processes across multiple cores -- not important for workstations when OS X was developed, since most were still single core -- but one of the main reasons that OS X Server has been one of the worst performing network OS's in the modern arena, with Linux and Windows blowing past it in terms of supporting network effiencies to multiple users. That said, Apple has apparently been working to shore up performance in this area and the latest DAW benchmarks show a considerable improvement in Cubase's performance on the latest version of OS X.)
You can see shootouts between the big 3 on the PC, Sonar, Cubase, and Reaper here:
http://www.dawbench.com/dawbenchdsp-x-scaling.htm
And you can check out the Cubase Win vs Cubase OS X benchmarks here:
http://www.dawbench.com/win7-v-osx-1.htm
Now, on to getting latency down... there are a lot of things you can do to make your host PC or Mac more efficient. (I'm a PC guy, of course, so I'll leave the light side to the experts in that quite different platform.)
In fact, it can be a detailed subject, but here's the broad overline: you want your hardware buffers (audio interface buffers) set as low as they will cleanly function. (If -- with your monitoring latency set way up to take that out of the picture for now -- you get glitches, stutters, etc from your incoming or playback audio, the HW buffering may be set too low. Check your maker's specs -- but they often have the very lowest that could possibly work as their spec [for the types of reasons cited above] so you may well have to set it above their spec'd minimum.)
You'll be able to keep both HW
and monitoring latencies down
if your host machine is running as lean and mean as possible.
That typically means making sure no other applications are running -- but you're probably
also going to need to look at
background operations/services/applets... the kinds of things that show up on the Task Manager's
Services tab.
That's usually the province of background programs like system utilities, always on anti-malware software, but also, annoyingly, many things that just should
not be running in background, often vanity/promotiuonal programs designed
just to put 'quick launch' icons in the systray -- yet they can take up many
megabytes of memory. Another prime offender are 'updater' programs. Apple is notorious for having buckets of background programs installed with their apps. (Got iTunes? You got background services up the backside. And try to get rid of them. Ha!) Quicktime itself has components it tries to install as always running. The Sun Java Updater (now owned by evil empire Oracle) can take as much as 12-15 MB of
your precious RAM just sitting around waiting to phone home every once in a while to check for an update.
Many -- most on many consumer machines -- of these background processes are absolutely unnecessary, except for
possible tiny gains in load time for the individual apps or for just getting a corporate icon into your systray.
Responsible software makers give you a way to tell these services and applets
not to load at startup -- but, unfortunately, many more do not. And many will load those services when the app runs and then
not remove them when the main app closes. It's just irresponsible software design. You're paying for their incompetence, vanity and arrogance.
A lean, mean, XP machine (for instance) might have as few as 10-20 background processes at startup and load in a RAM footprint as small as 100-120 MB -- but many consumer machines will have 70 or 80 background processes and their RAM footprint will be 300 or more MB
just sitting there.
And more if you run background anti-virus, which often does
little to protect careful users who don't do the
stupid stuff like opening unexpected email attachments, visiting (and even worse downloading -- but sometimes just visiting is all it takes) porn and warez sites, using uncontrolled p2p softare (torrentz, etc).
In fact, a study a couple years ago found that major anti-malware from companies like Norton, McAffee, and even the respected Trend Micro (maker of the normally very good, free online scanning service, HouseCall) typically miss as much as 80% of
current threats -- (which is typically all you really need protection from if you keep your browser, OS, and net-using programs properly patched).
For that reason, many wised up power user types eschew background A-V software.
But they
do follow the best practices that
everyone should follow: keep your browsers, OS, and net-using programs (which, these days, may be most of them) patched and up to date, and avoid known transmission vectors like porn and warez sites and torrentz, or installing untested/unknown software, making sure your system has thumb drive auto-run turned
off,* and so on.
__________________
* The early editions of XP had thumb drive auto-run defaultto on 
-- that's how 1/3 of the US private and military PCs in Afghanistan got infected back in the mid decade, GIs would buy cheap thumbdrives in the marketplaces -- most of them with factory preinstalled spyware from our friends at China, Inc., who like to make sure they know what other military powers are doing near their borders and has the technology to put it over on the US Pentagon -- which is long on particle beam weapons mounted on satellites but apparently quite short on everyday technology common sense.)
__________________
And finally, the other place where you can cadge a little extra efficiency, if you're a bit tech savvy, is in disabling unnecessary Windows system background processes (or setting them to start manually). That's well beyond the scope of a BB post but you can find various optimization strategies for the Windows flavors around the web.
Now on to a trickier, thornier issue:
A somewhat separate issue that arises out of various hardware and software system latencies is the problem of timeline (sometimes called tracking) misalignment.
This is a much more common problem than many people realize or than some commercial interests would like to admit.
And it was a problem where the industry was slow coming to the table, with DAW makers pointing at hardware makers (and the HW maker's driver programmers) and the HW makers sometimes pointing back at the DAW makers.
The problem was that many DAWs and driver systems either did not accomodate for HW latencies at all, or drivers misreported actual latencies. And that resulted in overdubs that were placed incorrectly on the timeline. (Usually by a stable amount, but in the case of some devices -- I had a USB mic with the issue -- the latency of incoming signals varied from 25 ms late to 40 ms late. If it had only been constant form session to session, one could have simply slid all new tracks x ms toward the timeline. A pain, but doable. But this device had a different effective latency every session. Fortunatley, I was able to use Mackie's old (abandoned) Tracktion DAW to record using it, and Tracktion had an quasi-automated ping-loopback timeline/tracking calibration tool that you could use to set a new compensation every time.
But not every DAW had that and some came to the table late on that. My own, beloved Sonar, only added a way to compensate for such tracking misalignment around 2006, IIRC, and a pretty minimal one at that, that forces the user to do his own measurement and calibration to adjust for unfixed latencies under either the advanced WDM-KS kernel streaming drivers or under ASIO drivers, which have some compensation but are usually not accurate in my experience.
A lot of folks will say things like, Oh, what's 5 or 10 ms? -- the time it takes sound to travel about 5-9 feet?
It might not seem like a lot, but at 10 ms, most folks can start to tell things are off -- they may not know how or why, but it's there.
And even less timing misalignment can become multiplied when a number of overdubs with such misalignement are made and summed. It's not too bad if all your overdubs pay strict timing reference to a central reference (like a drum or clicktrack) but if the overdubbers start taking their timing cues from other overdubs, you're wading into a sea of potential rhythmic confusion and imprecision as what was once an unambiguous rhythmic center becomes 'smeared' by numerous, seemingly arbitrarily off time overdubs.
