On 6 Jul 2016, at 18:01, Quincey Morris <quinceymor...@rivergatesoftware.com> wrote: > On Jul 6, 2016, at 03:06 , Jonathan Taylor <jonathan.tay...@glasgow.ac.uk> > wrote: >> >> a single lost frame will be fairly catastrophic for the scientific experiment > > If this is genuinely your scenario, then nothing mentioned in this thread is > going to satisfy your requirements. It is pure whimsy to expect any > prioritization mechanic to ensure that the capture is buffered around random > unrelated user interactions with the Mac.
All fair points, but the fact is that in practice it works remarkably well at the moment. There is still some spare i/o and cpu capacity, and in practice the 8GB of ram *does* act as a very effective, and very large, buffer. There is a clear indication displayed if a backlog starts building, and even a backlog of 1000 frames is easily recoverable without loss. A colleague had tried to transfer some old data to another machine for analysis during an experiment, and it became clear this was causing a backlog to build in the live recording. It was no problem just to cancel the Finder copy operation, and the live recording recovered and cleared the backlog. My question was just intended to explore whether there was something easy I could do to make that sort of low-priority background request more likely to work without causing conflicts. It sounds like the answer is probably not! (Though I have definitely learned some very useful stuff in the process) _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
