Re: large scale (audio) file I/O on OS X : help or insight requested
Re: large scale (audio) file I/O on OS X : help or insight requested
- Subject: Re: large scale (audio) file I/O on OS X : help or insight requested
- From: Hamilton Feltman <email@hidden>
- Date: Thu, 05 Mar 2015 18:48:30 -0800
Caching was disabled, but I had tried a lot of different tests, one of the was to remove lookahead reads and inadvertently it’s still in there. So this explains the more ‘deterministic’ results. But I think you’re going to need this also, since what you’re doing is writing your own file cache, and you don’t want the filesystem to think it knows better.
if (fcntl(fd, F_RDAHEAD, 0) == -1) { fprintf (stderr, "Cannot set F_RDAHEAD on file #%d\n", n); }
Ok, that clarifies the issue drastically. One thing to check is possibly something else hitting the disk, like spotlight. Anything else touching the disk at that seekrate, and the bandwidth is destroyed. You can disable spotlight for that drive (System preferences -> Spotlight -> Privacy). If it’s not spotlight, a utility called fseventer will show system wide file access, but it doesn’t look like mavericks is supported yet. But there has got to be a command line util that can watch fsevent.
Something to try anyway.
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden