Re: preferred disk api for high bandwidth sample reading
Re: preferred disk api for high bandwidth sample reading
- Subject: Re: preferred disk api for high bandwidth sample reading
- From: Brian Willoughby <email@hidden>
- Date: Sun, 3 Jan 2010 17:41:11 -0800
Nemesis solved your problem in 1999 by caching only the beginning of
all the samples in memory, leaving enough time to stream the
remainder of the samples from disk for notes that are held. This
allows low-latency startup times for every possible note sample, but
does not eat up memory by attempting to store the entire sample in
memory. Basically, you determine how much time it takes to react to
a Note On event and start streaming successfully from disk, and you
make sure that you've cached at least that much of the sample time in
memory. Unfortunately, this idea seems to be patented.
http://www.gigastudio.com/release.html
TEAC acquired Nemesis, and Garritan has acquired the Nemesis assets
from TEAC.
http://www.gigastudio.com/faq.html
There are even some who are attempting to maintain the Gigasampler
file format independently.
http://www.chickensys.com/support/software/translator/giga/
But your question - at least on the subject line - is focused on disk
API. I'm not even sure that this is a CoreAudio question, since no
disk access is allowed during audio callbacks. I suppose there are
probably some best practices that developers here could recommend
concerning the best file I/O for streaming. You'll also need some
sort of semaphore or other signaling to coordinate between the disk I/
O and the audio I/O.
Brian Willoughby
Sound Consulting
On Jan 3, 2010, at 14:17, Living Memory wrote:
I just read my original post, of course I meant 24 bit not 16
(brainstorm), and yes the sample data amounts to many gigs, far
more than can fit into memory.
Paul's observation probably says it all...
there is no
way to handle data on disk that provides any shortcut around careful
buffering&caching design
But really here I'm looking to gain from other peoples experience
using core-audio to develop sample readers of this scale on the Mac
as I don't want to have reinvent wheels if I can help it and the
previous threads on issues like this are quite old now.
_______________________________________________
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