Been using Ardour for years recording rehearsals, and twice now I’ve been not in my basement using it (interfaced with an x32) and was unable to get a clean recording.
The sample rate is 48KHz with 32-bit resolution. I admit I was not observing the buffer size, but presume it to be what it always has been in my basement - not doing anything realtime through my Mac, just recording and not even monitoring. IIRC, I was using an aggregate device. A new Mac Pro laptop and SSD was used w/ 16 channels. It is sure hard to keep an eye on everything when at a venue. What is frustrating is that the first 20 minutes during setup I checked playback and it was fine. Routinely use a Hackintosh with HDDs that is years old w/o any troubles.
The capture buffer looked fine, and for over three hours only one xrun was marked.
This is what was recorded after about 20 minutes (verified by loading the interchange wav files in audacity). Maybe someone has enough experience to hear the cause?
That’s just it, nothing was happening - Ardour isn’t complaining about the disks, only one xrun flagged on three hours of recording. It all looked good and initially played back perfectly so I did a set-it-and-forget-it for the three hours. Everything was as normal as it could be. But after 20 minutes, over two hours of audio consistently turned out as can be heard on that link I provided. I don’t have any other leads. I recall looking at the C buffer and being happy with it. Everything was left at default.
It is a hard set up, but am going to emulate things tomorrow (16 channels w/ signal left for hours). So more info then. I figure that someone with experience can hear the audio and definitively say what’s going on.
I’ve tried to use aggregate devices with pro tools and it did not work well. I suggest that you use your audio device directly and never use aggregate device in any serious work. After all it adds a layer of complexity onto your audio device and if you bundle multiple audio devices into an aggregate device that is just asking for trouble.
Also make sure that your buffer size is big (1024) when recording.
That is unrelated. This is the memory used when writing to hard-disk. x-runs are buffer over/under-runs for audio i/o issues to/from the soundcard.
The usual cause is that some other device or process hogs the CPU or Bus for a long time so the soundcard doesn’t have the opportunity to to request/provide data.
…randomly at ~20mins, that may be a screen/engery-star DPMS power-saving signal, but it could be anything. Issues like this are near impossible to track down.
I’m connecting to a Behringer X32 Rack via USB, so the sound card is an external UAC device (or one where MacOSX already has the driver).
So then what must be going on is that my rig (when at home) has internet access and is fine. But when not at home does not have internet access and is then not fine. I’m versant with computer, so can work through making an A/B comparison. 100% chance it is going to be some stupid process like dropbox or time machine that is consuming too many cpu cycles waiting on an Internet route. This issue will not catch me again, and I’ll report back my findings.
Thanks for the link to the computer system - will read. Didn’t start there because my two Ardour DAW rigs are a 2017 Mac Pro w/ SSD and an 8 core hackintosh with a performant HDD array, both of which can do heavy lifting.
I adore Ardour and have received incredible value for the past donations to the project. Maybe time to go for a subscription!
USB is notorious for not performing well with small buffersizes or cause dropouts on occasion e.g. bus probes, or when theres another USB device on the same bus, perhaps an internal device (camera, wifi are sometimes on USB) or an internal USB hub.
MacBooks are usually well designed with respect to that, but perhaps try a different USB port…
“Raw power” and “fast SSDs” have usually little to do with a DAW’s realtime performance. Realtime is about reliability, not about speed. – A rather elaborate explanation of “realtime performance” is
Alrighty… So it was CPU load and too small a buffer size. And since am just recording and not even monitoring, a much larger buffer size (4096) in conjunction with quitting and killing background processes did it. Still haven’t determined why this is not necessary when the computer is on a network. Maybe not having a network causes to much cpu load from things waiting around for the network.
Silly me for not paying attention to such things and ruining the recording of two live performances!
This is a good clue! It is weird that it happens when not on a network; I would rather have expected that it is the other way 'round.
Perhaps WiFI discovery? (that’s skipped when connected), try turning off WIFI completely.
It could also be remote backups, time-machine looking for a network drive.
On MacOS/X there were also some users reporting that DropBox and Adobe updater can get in the way (for whatever reason those processes run with high priority).
To rule out that it’s some background user process, you could try to create a new, non-admin user (easy on Mac, in Preferences) and recording using that new user-account. Ideally reboot and only log in as that user so that no other background processes of your normal user exist.