Apple

On Mar 11, 2015, at 9:07 PM, Paul Davis <email@hidden> wrote:

On Wed, Mar 11, 2015 at 10:57 PM, Hamilton Feltman <email@hidden> wrote:

> We know by existence proof (aka Logic) that the system can handle 128 or more tracks.

Yep, the tests you posted confirm it’s possible. Just double your buffer size from 65536 to 131072. Half the number of seeks, and track count goes from 49 to 100.

True, except that using dtrace while running logic shows that something is only reading 64kB at a time (and apparently the kernel, suggesting that logic is using mmap). Can't prove this without source, however.

Either something is wrong with the test, or logic is background caching. We’ve just proven that this drive can't do more than 50 tracks, with a 64kb read size. It doesn’t matter what the os is using. It is physically impossible for the drive to seek any faster when reading that blocksize. The only possiblity is that more time is being taken, i.e. background caching.

I can say with almost absolute certainty that the usual dtrace tools show Logic doing absolutely no (direct) audio file I/O during playback at all.

Logic is background caching as soon as the song is opened? You could test this by closing logic, clearing the file cache, opening logic and immediately starting playback while watching the trace. If it’s still reading in 64kb blocks, it’s going to stall, there are no two ways about it.

But it isn't that simple: increasing the block size makes it much more likely that you'll encounter a very large drop in minimum sustained streaming rate, in addition to a substantial increase in maximum sustained streaming rate. You don't see this in your results, but we've seen it in all of ours so far.