Someone posted before on this (http://puredata.hurleur.com/sujet-8900-audio-error-samples) but it seems the issue was never resolved.

It really didn't seem like it was interfering with my work until last night when I was recording and every once in a while the audio would cut out for a second and the console would display the red "audio I/O error" and would print nothing. The error also displays when I first turn the DSP on, as well.

This also happens to me only when using samples ([tabread4~]?) and not other objects; will confirm later. I'm running OSX 10.6, Pd-extended 43.4, and usually a MOTU 828mkI, though the error also appears when using the built in in/out. I'll test this in Linux later today (though not with the 828).

Maybe using jack as the driver instead of portaudio?

I would definitely suggest jack over portaudio. When I did tests on it on my old Macbook, jack gave a significant drop in cpu usage while also allowing for shorter latency. Make sure, of course, that you've installed JackOSX to use it.

While I wish Pd would be a bit more clear on what exactly it means by "Audio I/O Error", I imagine it's an issue with the I/O buffers not be filled. Usually, this is fixed by increasing the latency.

Ya, I started using jack but I haven't figured out exactly how to get my MOTU to run though it... Regardless, I was still getting the error after switching to jack so I've increased the latency to no issues yet (besides the big red warning I was talking about).

Will advise.

Ran into the error again today using jack as the driver and the MOTU828 (though it also happened without the 828). I ran the message [; pd audiostatus;( and it returned:

seconds ago error type
5.01 A/D/A sync
20.22 unknown
90.88 unknown

So it's some A/D/A sync error but that's all I was able to get out of Pd... This time it was happening with the DAC off (!) when I was loading files into a table. Latency was increased from 20ms to 50ms, then from 50ms to 100ms with no difference.

[update]: mostly have the audio drop error when I'm using [writesf~] writing a 24-bit file but the audio drop does not show up in the .wav file that's created... really confused. CPU runs at ~10%.

If you're using jack, the latency setting in Pd is meaningless. Instead, jack overrides it with the buffer size setting. So that's the one you should try increasing.

Though, if it's mostly when using [writesf~], I'm wondering now if it's more of a problem with writing to the hard drive. It might just be kind of slow, or it's possible [writesf~] isn't efficient. As you noticed from the file, it is writing all the audio. It's just not doing it fast enough to get the DAC buffer filled in time. I think.

That makes sense. I won't be able to test it again for a couple weeks cause I'm moving... I think you're right, though, to increase the buffer setting.

Thanks Maelstorm!!!