creeping playback buffer

[dannygold]

I have an issue on my MacBook 2ghz with 1.5 gigs RAM 10.4.11 DP 5.13. Sometimes the playback buffers slowly creeps up, up up up and then spikes in the red at which point I get dropouts in the audio. The CPU seems fine during this, running at less than 30 percent. This happens in big 96K projects with lots of tracks, but oddly also in small projects sometimes. Happens on both my FW410 and built in audio. This happens both on my internal drive and on a 7200 RPM external FW drive. One particular project displays this behavior and does so equally on both drives. It happens LESS when I run my prime seconds at 5.0 and work quanta at 500. On the default settings it just happens constantly. Very very oddly it seems to get better at least for awhile if I change buffers... not necessarily upwards, just a change. Like if I'm at 2048 it helps for awhile to go to 1024. Or vice versa. Maybe because this reloads MAS? I dunno... seems like if changing the buffers fixes it maybe the buffer is getting stuck somehow?


*ANYONE HAVE ANY IDEA WHY THIS IS HAPPENING?

*DOES IT HAPPEN TO ANYONE ELSE?

*ANY IDEA WHY BUFFER TOGGLING HELPS?

*WHERE ARE YOU GUYS RUNNING PRIME SECONDS AND WORK QUANTA?

*ANYONE ELSE HAD PLAYBACK BUFFER OVERLOAD ISSUES?

Who was that guy from MOTU that used to post here? Maybe he can help?

SIGNED
DANNY GOLD

[Dave Bourke]

Danny, I'm sorry I can't help you with your issue but I was immediately struck by the fact that, back around 2004/2004, MOTU used to employ an excellent tech support person named...

Danny Gold.

Kind regards.

[dannygold]

Yeah, I guess that's what they call "begging a compliment"

[Frodo]

Danny--

Part of it might be due to the size of the audio files @96k, and part of it may be due to the FW bus just being overly taxed at any one given time. This can happen with 44.1k projects as well.

Running apps and effects from the system drive is unavoidable because that's where they must be installed. Running all audio and VIs from an external drive appears to be indispensable.

One thing you might consider is adding an eSATA card to your card slot. Single and multi ports are available from various manufacturers. Sonnet is one maker I'd feel comfortable recommending.

http://www.sonnettech.com/product/tempo ... ess34.html

The advantage of eSATA is that the data transfer rate is closer to 3G-bits/sec whereas Firewire 400 is less than 1/2 of 1 G-bit/sec (0.4Gb/sec). The FW bus is 33Mhz and the eSATA frequency is closer to 1500Mhz. Through-put is vastly improved with eSATA and the benefits are remarkable.

You could try going FW800 to see if that helps, but then you'd maxing out at less than 1 G-bit/sec (0.8 Gb/sec). This approach only makes sense if your current FW drives already have FW800 ports on them. Otherwise it's not really worth the trouble or expense to try it out.

As for Work Quanta, etc... mine are set at default currently as I have less a desire or need presently to redirect resources from video performance to audio. However, a review of what these features do (such as is known about them) can help to determine which will address your particular issue.

While Prime Seconds does nothing for VIs, it might help with pre-rendering of audio. Some people prefer not to pre-render, so please accept my apologies for a lack of more definitive advice on this.

FWIW---

Work Quanta is apparently the interval (in milliseconds) at which the MAS engine does its calculations. Work Quanta is not Buffer Size ••” that's still there in the Configure Hardware Driver dialogue box ••” and MOTU suggest it should normally be left at its default value of 100, but they also say that increasing it favours audio performance at the expense of graphical interface smoothness. At its maximum value of 500, I fancied there was a slight reduction in processor hit for an instrument-heavy sequence I was working on, so it may be worth experimenting with on your own Mac.


Perhaps pointing to some reworking of DP's audio system, MAS, the Configure Studio Settings dialogue box in DP5 sports some interesting new settings.
Prime Seconds is more mysterious. This setting seems to control how far ahead DP looks to 'pre-cue' the audio in your tracks when you locate the playback wiper in a sequence. Higher values potentially help with processor spikes that occur shortly after playback begins. But Prime Seconds also relates to something else new, and more puzzling still: pre-rendering.

Specific details on this new feature are tantalisingly scant, but it seems to work like this: when you place a plug-in on an audio track, dial in some settings and then close the plug-in's window, DP5 'pre-renders' audio in the track just ahead of the playback wiper, to sound exactly as though it was being treated in real time by the plug-in. The amount that is pre-rendered would seem to be equal to the Prime Seconds value, and is heard as soon as you start sequence playback.

more--
http://www.soundonsound.com/sos/jul06/a ... h_0706.htm

[Phil O]

...Sometimes the playback buffers slowly creeps up, up up up and then spikes in the red at which point I get dropouts in the audio....

When I first got my MacPro, I ran some torture tests to see how far I could push it before it would break. I found that as I approached the limit, things did not simply peak and crash, but instead there was a steady "creep" in the playback buffers (as you describe) until finally it would hit the red and crash and burn. This creep seems to be the way the playback buffers overload and you need to find the point where they will max out without creeping up. I don't know how else to explain it, but it sounds like you just need to reduce your track count (or perhaps get a faster hard drive). Also, are you recording to your boot drive or a second drive? Could make a difference.

Phil

[dannygold]

Thanks for the suggestions. I'm on a macbook, so no ability to connect my drive to FW800 or eSata via PCMCIA card. But I really don't think it's a drive issue because the buffer creep is exactly the same whether the file resides on the internal 5400 RPM drive of the macbook or a brand new fast 7200 RPM FW drive. All well and good to blame it on the drive, but it should be at least somewhat improved on a way faster drive right? The issue is identical on both drives. Also this... I noticed the the playback buffer creep started in the same place in the song every time. After the last chorus. Until then it was fine with about the same track count. So I tried merging soundbites thinking a bum soundbite was causing the issue. Same problem, same place. So I played with my hardware buffers. Same issue at the max, 2048 with a multiplier of 4. Same issue back at 2048 with a multiplier of 1. Tried 2408 with a multiplier of 2 and it was FINE. The buffer not only didn't creep, it was running at like 10 percent with only a tiny fill/release. So what's up with THAT I think... what's so special about 2048 X2? So I went back to 2048 (which remember didn't work a minute ago) and things are fine again. Totally fine. I just can't blame this on drive performance. My theory is there is some interaction between the hardware buffer and drive performance and it something in that interaction gets "stuck"... kind of like a RAM leak if anyone knows what that is. By resetting the buffer (repeatedly in this case) you can clear out the issue. Some kind of MAS thing I'd guess.

[pcm]

On a slight tangent, I have a MBP, and BOTH eSATA and firewire cards for it. FW400 bandwidth will allow for 30 to 35 megs per second, with is below the speed of pretty much any drive hooked up to it. eSATA (as a bus) supposedly can reach 150 megs per second, which is way above any hard drive made. The same drive I used in my fw test gave me 60+ megs per second in an eSATA case (a Seagate drive).