Logic Pro 9 I/O Safety Buffer?

paulnajar

Logician
In Logic 8 in the Global Audio Drivers preferences there was a checkbox to turn of the core audio I/O safety buffer. It's not there in Logic 9. The manual makes no mention of any safety buffer either.

When looking in AU Lab connected to a FireFace UC it says there's a 24 frame (sample) safety buffer both in and out.

Am I to assume that Logic 9 will not run at as low a latency as Logic 8?

Kind regards
 
In Logic 8 in the Global Audio Drivers preferences there was a checkbox to turn of the core audio I/O safety buffer. It's not there in Logic 9. The manual makes no mention of any safety buffer either.

Hi Paul

It has been removed completely in Logic 9.

When looking in AU Lab connected to a FireFace UC it says there's a 24 frame (sample) safety buffer both in and out.

Am I to assume that Logic 9 will not run at as low a latency as Logic 8?

Actually, using the I/O Safety Buffer in Logic 8 increased Logic's latency. The 24 frame (sample) safety buffer you are referring to is presumably the F/W buffer.

kind regards

Mark
 
Upvote 0
Hi Mark. The fact you could turn it off in L8 was a benefit - less latency. Thus my question about 9 not able to go "as low" as 8.

The FireFace UC is actually a USB2 interface FYI. I'm not sure if Core Audio does different safety buffers under different data ports - firewire, USB2, PCIe etc.

Kind regards
 
Upvote 0
The FireFace UC is actually a USB2 interface FYI. I'm not sure if Core Audio does different safety buffers under different data ports - firewire, USB2, PCIe etc.

Hi Paul

Ah, sorry, knee jerk reaction on my part. Fireface = FW no longer holds :redface:

I don't know whether there is a USB safety Buffer similar to the FW Buffer, although AU Lab seems to indicatet that this is indeed the case. AFAIK, PCI/PCIe is slightly faster in this respect, it does not require this type of safety buffer - one reason why PCI/PCIe systems have slightly better Latency throughput values compared to FW. THe tests we posted a while back on the mailing list are worth looking at:

http://tech.groups.yahoo.com/group/logic-users/database?method=reportRows&tbl=18

kind regards

Mark
 
Upvote 0
Even though there's no choice for I/O Safety buffer in L9, my guess would be that it's not used/disabled.

It generally caused more problems than it fixed.

howard
 
Upvote 0
Even though there's no choice for I/O Safety buffer in L9, my guess would be that it's not used/disabled.

It generally caused more problems than it fixed.

This is absolutely correct.

When it was removed, it was completely eliminated. So Logic 9 has no extra latency over Logic 8.

And it was removed because it was an absolute dog, in nearly every situation. Thats why I always advised everyone to turn it off.

Orren
 
Upvote 0
Thanks everyone for the response. Oreen I hear you and yes I never ran with it on but then this leaves one question. Why does AU Lab report the 48 samples as a safety buffer? My assumption is that in L7 the buffer was permanently on. In 8 they gave us a choice. In 9 are you certain it's off?
 
Upvote 0
Why does AU Lab report the 48 samples as a safety buffer?

Don't know, never used it.

My assumption is that in L7 the buffer was permanently on. In 8 they gave us a choice.

That assumption is incorrect.

In fact, the I/O Safety Buffer was a brand spanking new buffer, added for the first time. It was added because they thought that by locking input to one core and adding an extra buffer, it might make recording more bullet-proof. However, it was a complete and total resource hog, and was removed completely.

In 9 are you certain it's off?

It's more off than off. It's gone, gone, gone.

Logic 7: Logic has 2 internal buffers (I/O Buffer, Process Buffer)
Logic 8: Logic has 3 internal buffers (I/O Buffer, I/O Safety Buffer, Process Buffer)
Logic 9: Logic has 2 internal buffers (I/O Buffer, Process Buffer)

Can't tell you anything about AU lab, though.

Orren
 
Upvote 0
In fact, the I/O Safety Buffer was a brand spanking new buffer, added for the first time. It was added because they thought that by locking input to one core and adding an extra buffer, it might make recording more bullet-proof. However, it was a complete and total resource hog, and was removed completely.

MainStage 2 still has it and it has advantages in MS, because it can help _lowering_ you latency. If on your system 128 samples work fine, but 64 do not. You should try to activated the safety buffer with a 64 sample buffer. This way you have a 96 sample latency, which might work for you.
 
Upvote 0
Thanks for clearing that up Orren.

FYI AU Lab is part of Apple's own developer tools which get's installed if you install the XCode tools - so I'm guessing that it's honest. A few years ago quite a few of us got busy on the Logic list running a latency test song to measure I/O latency and during that period my test results were confirmed by AU Lab's figures...

Interestingly AU Lab reports a 34 sample safety buffer one way when using the built in outputs of my 2008 MacBook Pro as well. It won't allow me to use MBP inputs.

I'm going to go run this thread over at the RME forum to see what the developers over there have to say about it all.

Kind regards

PN
 
Upvote 0
OK so I got carried away a bit this arvo and did some of my own testing thinking I would post some questions to the RME list but it all added up pretty well perfectly so I share the following for anyone who may want to know.

All figures stated are for 44.1KHZ sample rate.

The Main software I use is Logic Pro9 and it's lowest buffer setting is 32 samples.

In Logic 9 at 32 sample buffer it reports a round trip latency of 4.6 ms. At 44.1 samples per ms that equals 202.86 samples - which is a lot more than 2 x 32 samples.

To verify this value I set up and recorded a metronome to an audio track. Via a bus I routed this audio track to an analog output on the FireFace UC and then patched this output back into and analog input. I then recorded the non looped back audio track together with the looped back audio track into a stereo file. By going into the sample editor and selecting the range of samples between one side and the other it showed a 198 sample difference - pretty close to the 202.86 samples Logic reports. So far so good. So if the buffer is only 2 x 32 samples where does all the other delay (latency) come from?

According to the FireFace UC (FFUC) manual the AD+DA conversion takes 1.6 ms or 70.56 samples. Add this to the 64 sample round trip buffer: 70.56 + 64 = 134.56

Also according to the FFUC manual the FFUC adds another 32 samples playback side only adding to a total of 166.56 samples accounted for.

Then add in the Core Audio safety offset.RME's take on this once again from FFUC manual is that Core Audio ALWAYS imposes an in and out safety offset that varies from device to device. RME spec the FFUC at 28 samples in+out. Add that to the 167 samples an we get to 195 samples - which is close enough to the 4.6ms or the 198 samples I measured myself in my test.

So put simply:

64 samples - 32 + 32 (Logic's buffer)
71 samples - AD+DA conversion
32 samples - FireFace UC playback buffer
28 samples - Core Audio Safety Offset

195 samples - total

That leaves somewhere between 3 and 8 samples unaccounted for. I rounded up all my figures.

Phew. So finally it does appear that AU Lab reporting 24+24 samples safety buffer is not quite right but not far off and yes Core Audio does impose a safety offset that "apparently" varies from device to device - but it (Core Audio) does impose an offset for every device that uses it and that's all of em except Digi TDM AFAIK.

Kind regards
 
Upvote 0
Back
Top