Audio Playback Overload

[hamburski]

Ok, I'm wondering how this is possible. I am running:
New 6-core Mac Pro, 16GB Ram, OS X 10.9, DP 8, two 1TB external SSDs for samples and sessions. I'm running all the latest updates of my Spectrasonics and Native Instruments plugins. I'm currently working on a session with a 10-minute quicktime file loaded and just three - count 'em - tracks so far: an acoustic guitar track with one DP plugin on it, an electric track with one instance of Guitar Rig 5, and one Omnisphere instrument. And I'm bussing the acoustic guitar out to two parallel instances of DP's Proverb.

I have the buffer on 128 - ok, but I've done that on my old dual-core Snow Leopard rig with a lot more running.

And yet - I am getting this: "Audio playback has overloaded your computer's processor. DP has detected an error in the audio. Samples may have been dropped."

If I click Continue and hit play again, there's no click, and soon after I get: "DP is not receiving a clock signal from the audio hardware. Check to make sure hardware or peripheral settings are setup correctly or disable the audio hardware for MIDI playback only."

And, sure enough, then there's no sound, and I have to reboot my interface, relaunch its software (Maestro), and reboot DP.

Oh yes, and I'm using an Apogee I/0 (2x6) with the latest firmware and software.

Based on other threads, I've considered monkeying with other hardware configurations - currently I have the work priority on High and the host buffer multiplier on 1.

I've opened the Audio Performance window and there seems to be room to spare, though I see that when starting or stopping playback there will be a momentary spike into solid red, which seems suspicious.

Obviously I was assuming that, having upgrading so dramatically after seven years on my old machine, this sort of thing would be nonexistent. My bad for drinking the Cupertino Koolaid, I guess...

[bayswater]

Same problem here some time ago. I tried a few things listed below. Things settled down and I haven't see the problems since although I don't which, if any of these solved the problem.

Turn off the Audio Performance meter, and never look at it again. Look at Activity Monitor and see what it says.

Look in Activity Monitor to see if CPU spikes happen at the same time that disk activity spikes. Maybe there's a problem with disks.

Following on the possible disk problem, look VI settings that determine how much sample data your VIs preload. With MachFive, I set this to the maximum possible, taking advantage of as much RAM as the VIs are able to use. Also check out pre-rendering in DP.

You might not expect the timing problem reported by DP would be the cause of CPU overload, but I've had the same symptoms (reports of CPU overload) using an ADAT source for timing. Switching to WordClock or Internal made that go away.

One thing to keep in mind when you get to a higher track count: DP works better on multi core machine using a separate instances of the VI, each with a small number of sounds, than a small number of VI instances each with a lot of sounds loaded.

[mikehalloran]

I have the buffer on 128

This is normally the culprit.

Now, before you feel the need to write pages as to why it shouldn't be an issue, increase your buffer on playback and see if you still have a problem.

[Shooshie]

Ok, I'm wondering how this is possible. I am running:
New 6-core Mac Pro, 16GB Ram, OS X 10.9, DP 8, two 1TB external SSDs for samples and sessions. I'm running all the latest updates of my Spectrasonics and Native Instruments plugins. I'm currently working on a session with a 10-minute quicktime file loaded and just three - count 'em - tracks so far: an acoustic guitar track with one DP plugin on it, an electric track with one instance of Guitar Rig 5, and one Omnisphere instrument. And I'm bussing the acoustic guitar out to two parallel instances of DP's Proverb.

I have the buffer on 128 - ok, but I've done that on my old dual-core Snow Leopard rig with a lot more running.

And yet - I am getting this: "Audio playback has overloaded your computer's processor. DP has detected an error in the audio. Samples may have been dropped."

If I click Continue and hit play again, there's no click, and soon after I get: "DP is not receiving a clock signal from the audio hardware. Check to make sure hardware or peripheral settings are setup correctly or disable the audio hardware for MIDI playback only."

And, sure enough, then there's no sound, and I have to reboot my interface, relaunch its software (Maestro), and reboot DP.

Oh yes, and I'm using an Apogee I/0 (2x6) with the latest firmware and software.

Based on other threads, I've considered monkeying with other hardware configurations - currently I have the work priority on High and the host buffer multiplier on 1.

I've opened the Audio Performance window and there seems to be room to spare, though I see that when starting or stopping playback there will be a momentary spike into solid red, which seems suspicious.

Obviously I was assuming that, having upgrading so dramatically after seven years on my old machine, this sort of thing would be nonexistent. My bad for drinking the Cupertino Koolaid, I guess...

Some things you might try:

Buffer = 256 samples
Turn off warning dialog
Work Priority = Medium (you can read about it in the "Getting Started" (the little) manual, page 23)
One instance of ProVerb

Omnisphere (from what I've heard) can be pretty CPU intensive, too. But really, three tracks of ANYTHING shouldn't stifle a yawn out of that computer, much less break it into a sweat. A 256 sample buffer shouldn't cause much latency with that rig. In fact, it may be preferable to 128 samples, because it reads so fast, yet it still has to process the tracks, instruments, and plugins in that short time.

My experience has been that the faster CPU doesn't necessarily make lower buffer rates much more desirable. (I've finessed that statement, because it DOES improve, but not as much as you would expect.) The reason, as I have thought it through, is probably because it does read them so fast, narrowing the processing margin as a result. Thus, any speed increase is negatively compensated by the resulting decrease in processing time, compared with a slower computer which requires more time to read the samples.

Put another way: lower read-time latency means less time to process other stuff. So, the buffer numbers aren't really going to go down as much as you'd think. However, they DO go down. I used to have to run at about 1024 samples for mixing. Now I can do it comfortably at 512. In order to track back in the PowerPC days (Dual G4), I had to turn off all plugins and instruments and track with MIDI at 64 or 128 samples to avoid noticeable latency. Now, I can leave most things running (if they don't have a built in delay such as look-ahead compressors) and track at 256 or 128. So, things are a LOT BETTER. But 128 is definitely stretching it with two ProVerb instances and Omnisphere. ProVerb has to do its thing no matter how many tracks you have. You could be feeding each instance 1 or 100 tracks, and the time would be the same.

Experiment with Work Priority. Some 3rd party audio interfaces actually require it to be set to LOW. Work Priority and Work Quanta are confusing, and when you read about them you have to absorb the information slowly, working through imagined virtual scenarios as you read so that you can get a grasp of what it's doing. I think I explained that somewhere in the Tips Sheet long ago, but I've long forgotten what I said!

[scurry-scurry... finding the tip]
Actually, it was Frodo who said it (I helped a little):
(Bear in mind, this was for DP5! But the principles remain the same.)

• Category: Setup, Operation
  Understanding and optimizing operations in DP5
  Accessed: Audio Setup Menu, Preferences; works everywhere!
  
  DP5 has three new features in the Configure Studio Settings dialog for optimizing audio engine performance, all accessible at Setup-->Configure Audio Settings-->Configure Studio Settings.
  
  1. Prime Seconds-- a "look-ahead" feature that pre-renders audio and effects, and pre-cues this data before playback begins.
  
  While MOTU recommends, ironically, leaving these settings at factory default, you may try lowering the Prime Seconds number to improve responsiveness of the space bar.
  
  2. Work Quanta-- adjusts the time intervals MAS refreshes its calculations. Raising this number can free up CPU resources to redirect them towards audio tasks at the expense of sluggish graphic display, including wiper performance. Lowering it improves graphic displays and any animation like moving faders, but at the expense of using more CPU resources.
  
  3. Max Work Percent-- Allows you to assign how much CPU horsepower goes towards pre-rendering for playback in percentages. Higher values give the audio engine more leg room at the expense of graphics and animation responsiveness. Lower values do the opposite.
  
  4. Buffer Sets the delay between the time you press a key, and the time that playback begins, or the time that a note plays.* With options for 128, 256, 512, 1024, and sometimes 2048, the buffer can make a huge difference in how many plugins or VIs DP can handle at once. For recording and overdubbing, cut latency as much as possible with a low setting. For playback and mixing, higher settings are permissible, allowing for more virtual instruments, reverbs, compressors, and other CPU hogs. Located in the Setup menu-->Configure Audio System-->Configure Hardware Driver."
  
  *This isn't literally what the buffer does, but for understanding it for our purposes, that's the noticeable effect. In fact, the buffer sets aside a small part of memory to hold audio samples briefly for easing the transition from hard disk to the CPU. Larger buffers hold more samples and require less I/O operations. Smaller buffers are faster but keep the processor busy retrieving data. The units for buffers would be "samples" as in audio samples. 256 samples takes about 13 milliseconds between reading and playing.
  
  5. Host Buffer Multiplier - increases the total buffer appropriately for each audio driver in use. Smaller is faster. Larger may reduce CPU strain. Increment 1 for each audio driver currently selected in Hardware Setup. Further increases may help in some cases.
  
  6. Work Priority - Sets OS X's priority for dealing with Digital Performer's MOTU Audio System operation thread. If you're using 3rd party software concurrently, such as Virtual Instruments or external processors connected by "Rewire" or "Soundflower" or "Jack Tools," then you may want to lower the Work Priority setting to allow more CPU attention to those applications. If DP is all alone, then by all means raise it to High.
  
  7. Background Processing - found in the Preferences Panel --> General --> Background Processing. Turn off the automatic processes that you don't use often. You can always turn them back on or trigger them manually. These will slow down your system as you add tracks, making for occasional frustration.
  
  8. Overload Alerts - Turn off "Show alert when playback overloads the processor(s)" at Preferences --> General --> Audio Options. While it may be nice to know, it can happen often, and it interrupts your work for very little gain. The interruption itself sometimes can be a problem.
  
  9. Use V-Racks for Virtual Instruments, Limiters, Reverbs - If you have a project with multiple chunks, and each has its own virtual instruments (VIs), centralize access to those VIs by loading them into a V-Rack. Select your VI tracks and choose Projects-->Sequences-->Move Selected Tracks to V-Rack. Alternatively, go to V-Racks by opening the Mixing Board and clicking on the V in its header. Then navigate the menu bar to: Project-->Add Track-->Instruments-->Add Instruments-->and fill out the dialog box. Instruments or plugins in V-Racks are available to all Chunks in the current project via I/O through busses. For greater ease, name your busses for the specific instruments and plugins they represent by using the naming functions in the Audio Bundles window. (Studio-->Bundles) Once done, VIs not currently in use by an inactive chunk will no longer be taking up CPU cycles.
  
  As we think of other optimization tips, we will add them here as well.
  _________________
  Frodo and the Editors at the Shire
  --------------------
  --------------------

Ok, that's about all I can think of at the moment. There may be other things involved, such as other processes running on your machine outside of DP, but getting your system running as fast as possible is as much art as science, and you have to develop a feel for what your computer is telling you, so this should be your exploration and discovery, not ours!

Shoosh

[hamburski]

Mike H - will do . I ran at 256 on my old rig and that was fine; somehow I thought I should go for the gusto with the new one and see what happened. Now I have. Back to 256 it is.

Shooshie - Many thanks for such a detailed rundown of the various factors. I had no idea what most of those parameters actually did! Now at least I have a glimmer. It will indeed take multiple read-throughs, and experimentation, to absorb what it's all about, but I no longer feel like I'm *just* guessing when I doink around with the numbers.

Again, let me express my appreciation for the resource that is this forum.

H.

[bayswater]

I have the buffer on 128

This is normally the culprit.

Now, before you feel the need to write pages as to why it shouldn't be an issue, increase your buffer on playback and see if you still have a problem.

I usually run DP at 128 if I'm tracking guitars with effects. Often I forget to change the buffer back to 512 where I would normally set it, but I don't have these problems. Clearly 256 will perform better than 128, but I don't think these problems should be happening at 128. The OP was running his old system at 128, and it had less CPU capacity. So there have to be other things that can be done to solve this problem than simply upping the buffer.

[sayatnova]

I just had my first session tonight with almost the same exact machine you mention: nMP 6 core, 16 gig RAM, although ext 7200 spinner HDs (not SSDs), Apogee ThunderBridge-Symphonhy IO.

I was trying to use a working project copied from the old machine (2008 quad 2.6 macpro, 10.9.5, DP 8.07) and just opened on the new machine, and got the same error message of "problem with playback/audio samples dropped..." and long hang times of spinning beach ball of death with audio dropping out and DP just choking. Changing the buffer to 1028 did not really help: still choked. Repaired permissions, rebooted everything, tried again: then got a "can't read the disk" messsage... (the ext. HD did turn up a single bad sector when I tested it with the latest TechTool Pro before harvesting it from my old machine. The disk was then formatted with the "zeroed out" option which was supposed to map the bad section and keep the disk workable. Subsequent scans showed all fine with the disk before I went ahead and put it into service. I guess it was not OK, after all.

Ended up creating a new project session on another ext HD (luckily had a second one) and loaded the sequence via the chunks load pathway from the working project on the old machine and voilà, everything worked perfectly. Was able to run 10 tracks playing back and 2 being recorded at 88.2, with a 64 buffer with barely any load showing on the processors! Very fast, very responsive. Got all VOX done for 2 tracks on the new album. Excellent.

So, in my case, creating a new blank project and loading the chunk in from a working backup session (on a healthy HD) fixed everything for me.

Hopefully this might be helpful to you.

~Shea

[BKK-OZ]

Could it be the background indexing that a new OS install does?

My NMP (now 10 months old) was really bogged down for ~2 days while the background indexing ran. I now run VI-heavy projects @ 128 buffer all the time.

[hamburski]

Update: been running for a few days now at 256 and things seems smooth.

Shea, I am using a template imported from my previous machine. Maybe it's worth taking the time to build a new one on the new machine and see if that helps.

BK - given that I have been running for a few days now, I'll try taking it back down to 128 and see what happens.

Good to know that you're both running at those low buffer settings and doing fine.

ham

[sayatnova]

Ham,

I would definitely rebuild a fresh template, and shoot it out against the old one. My machine had been running for three days after the initial set-up and I still had the issue... Just saying... It is easy to do and you will have more of an answer to your problem.

In fact, I will be trying to just copy my old backed-up working project from my old machine to the working HD and see if that works today. If not, I know the whole "make a new project and load/import the sequence from the back-up into it" already works. If it works, then maybe my problem was most likely related to the dodgy ext. HD. If not, then it is an odd format issue between machines, in spite of the same OS and DP version on both...

~Shea