Le 12/03/2015 05:07, Paul Davis a écrit :
On Wed, Mar 11, 2015 at 10:57 PM, Hamilton Feltman
<[email protected] <mailto:[email protected]>> 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. 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.
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.
I've made a streaming engine on OSX as well and I have noticed a weird
cache use indeed.
It didn't made sense in my Sampler use case (way too many possible file
played for a only very small time, although it seems that some other VI
makers do it) but I wonder if nmap wouldn't be a better approach for you.
Boost provide a Windows/Unix version FWIW
http://www.boost.org/doc/libs/1_56_0/libs/iostreams/doc/classes/mapped_file.html
my 2 cents.
--
Olivier Tristan
Research & Development
www.uvi.net
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com
This email sent to [email protected]
