• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: preferred disk api for high bandwidth sample reading
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: preferred disk api for high bandwidth sample reading


  • Subject: Re: preferred disk api for high bandwidth sample reading
  • From: Paul Davis <email@hidden>
  • Date: Sun, 3 Jan 2010 20:48:56 -0500

On Sun, Jan 3, 2010 at 8:41 PM, Brian Willoughby <email@hidden> wrote:
> 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

its not clear that the patent would stand in court. substantially same
system has been (re)implemented by (at least) steinberg within halion,
and its not unlikely that other sampler engines have done the same.
more importantly, perhaps the language of the patent is loose enough
that it might be at least partially invalidated by the unix buffer
cache's readahead algorithm. suffice it to say that on most unix
systems (include OS X), if you read the first byte of the file, the OS
will do 95% or more of the rest of what you need, without knowing
anything about sampling, notes or audio. this is highly subject to the
specific filesystem you are using and specific settings of the kernel
buffer cache mechanism, whose semantics vary between (say) Darwin (OS
X), Solaris, Linux and FreeBSD.

> There are even some who are attempting to maintain the Gigasampler file
> format independently.
> http://www.chickensys.com/support/software/translator/giga/

see also http://linuxsampler.org/ which despite its name runs on OS X,
Windows and Linux.
 _______________________________________________
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

  • Follow-Ups:
    • Re: preferred disk api for high bandwidth sample reading
      • From: "Ross Bencina" <email@hidden>
    • Re: preferred disk api for high bandwidth sample reading
      • From: Sean Costello <email@hidden>
References: 
 >Re: preferred disk api for high bandwidth sample reading (From: tahome izwah <email@hidden>)
 >Re: preferred disk api for high bandwidth sample reading (From: Paul Davis <email@hidden>)
 >Re: preferred disk api for high bandwidth sample reading (From: tahome izwah <email@hidden>)
 >Re: preferred disk api for high bandwidth sample reading (From: Living Memory <email@hidden>)
 >Re: preferred disk api for high bandwidth sample reading (From: Brian Willoughby <email@hidden>)

  • Prev by Date: Re: preferred disk api for high bandwidth sample reading
  • Next by Date: Re: preferred disk api for high bandwidth sample reading
  • Previous by thread: Re: preferred disk api for high bandwidth sample reading
  • Next by thread: Re: preferred disk api for high bandwidth sample reading
  • Index(es):
    • Date
    • Thread