Buffer Errors in MOTU Digital Performer

DP in use

DP in use

As I have been WAY behind on this, my personal blog, I have decided to start it up again.  I have plans.  things will happen.  Excitement shall ensue.  In the meantime, I am creating this new category so that I can post random bits of technology/I.T. information.  This is the geek in my, but oftentimes I find amazing solutions to complex problems and both would like a record of this and like to keep it for those cloudy days when I need a justification to keep going /sarcasm.

So here’s one in regard to issues we were having at work with MOTU Digital Performer.  An application well suited for recording, but notsomuch [sic.] intended for use as a primary playback platform.  Well, the patter is how the show is run and done so here I am, making teh best of what I have to make the best with.

In regard to the various Purple/Blue crashes, the following report summarizes both the problem and provides three individual recommended actions.

Primary Concern:

Audio Blue crashed a couple times last week during operation of the show and Audio Purple crashed last night during operation of the show.  The error reported was in regard to the Digital Performer (DP) Buffer being over-run and advises the operator that, in order to continue playing, DP would stop disable some tracks (not good for a live show obviously).

Upon RM’s call last night in regard to Purple, I checked the console on both machines, verified that they were restarted between shows (they were, but Purple had rolled the show, then was set to start and again rolled for some reason), posted some questions to Mahalo and Experts-Exchange, opened a ticket with MOTU and waited for the show to end after which time I grabbed all the detail logs and updated my questions on those services.


A. This type of buffer problem is specific to DP.  The machines were never over 27% of their 4-core CPU load and there was plenty of physical memory available at the time of the error.  Also, the machines were active (not idling) and no other processes were hung.  In fact, DP was not hung.  That DP was active, not hanging and not dominating the system means the problem is DP internal.  All answers obtained from the various services I posted to agree on this point.  So the machines and their set-up are stellar, DP has the issue.

B. This exact error in DP is internal to DP.  DP utilizes two different buffer types: instruction and waveform for lack of better terms.  While MOTU suggests (both via the actual error dialog box and via their support FAQ online) reducing the number of elements within the DP project file in order to alleviate the error, there is something missing from this request:  a differentiation between the types of data being buffered.  The instruction buffer is where MIDI commands live.  Theoretically you can store 255,000 MIDI commands in this buffer without causing DP to even flinch.  It is the waveforms that are the real culprit here.  Consider the Pretty Girl section: multiple and large bits of data all in one block.  As DP moves thru time, the buffer remembers what has been (in case you need to snap back), what is (obviously) and what will be (so you can cue fast).  At this point in the show, DP is being asked to remember a whole lot and prepare for a whole lot more in the intermission where you have not just audio but also video.  A lot of waveform.

C. Upon speaking with the Audio staff this a.m., I learned that this problem occurs at the same point in the show each time this problem happens.  PATTERN (see recommendation #1 below)!  It happens at the tail of “Pretty Girl” (PG) prior to the intermission.  Copper mentioned that McHenry used to have PG cut-up into smaller chunks and segments.  While no one on site knows the ever important why when reflecting upon Mr. McHenry’s methods and/or rationales, we had assumed that the had segmented the show in this manner for issues of control.  However, it could very well be to free up the DP buffer which makes a lot of sense.  See recommendation #3 below.


1. I would like Audio to start using the Excel spreadsheet log found at:
/Volumes/Department Folders/Production/Audio/Logs/Digital Performer Anomaly Log.xls
whenever a computer-related anomaly occurs.  I have created it to tell me and them as much data as we need.  This spreadsheet gives myself and other operators a record of the anomaly and assists in identifying both patterns and problematic portions of the DP project file.  I believe this to be an excellent diagnostic piece of the proverbial pie.

2. Audio Gold will research and report to me on How to Increase the Available Buffer size within Digital Performer.  he said he has time to perform this research while waiting on renders in the Editing Bay today.  While we both believe the buffer to be at the 1Mb max due to the bit depth of the host operating system, this needs to be confirmed. (example: increasing to a 2Mb buffer would require a 64-bit OS which would cost – per unit – $99 for the OS upgrade and $250 for the DP version compatible with the new OS).  If our slightly informed hunch is correct, no action is merited beyond documenting the why but if there are other, free things we can do to increase buffer we will do so.

3. Audio should cut the “Pretty Girl” chunk/seg in half in order to reduce demand upon the DP internal buffer as discussed above.  This is the primary action to alleviate the primary concern above.  If the buffer continues to overfill proceeding this action, the same cutting will need to happen to the intermission so as to reduce the next buffer block in addition to the previous/current buffer block.

Category: Technology  Tags: ,
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>