• 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: tahome izwah <email@hidden>
  • Date: Sun, 3 Jan 2010 19:49:30 +0100

Just my 2 cents: With memory getting cheaper all the time and MacOS X
being (mostly) 64bit now I would read all the (relevant) samples into
memory rather than streaming from HD. The way I see it your app is
going to need a hi end Mac anyway so it could as well use the
available RAM rather than read from HD (which is comparably slow). I
guess there must be a clever way to figure out what data you need and
when, so you can preload at least that part.

--th


2009/12/30 Living Memory <email@hidden>:
> Core audio'ers ....
>
> I've read through some very interesting threads on this subject but most are now a few years old...
>
> I've authored reverbs and synthesisers and such so I know a fair bit about core-audio and audio unit development.
>
> But I now have a requirement to read 96kHz 16bit  monophonic audio from disk to get as high a polyphony as possible hopefully at least 64 notes.
>
> The samples are many and huge,  lots of gigabytes of data on disk!
>
> It feels to me that a sample reader instrument of this kind  would require a fairly large bandwidth but there is no requirement  to apply any dsp, simply to read the sample data  ( per note ),  mix it and output it in stereo.
>
> I have a couple of questions:
>
> - Can anyone give me an idea of what kind of performance I should expect to achieve from such an Audio Unit running in say, Logic or Performer,  is 64 notes a realistic expectation on say a new MacBook Pro or Mac Pro  ( circa 2009 )?
>
> - Previous threads discussing disk bandwidth have pointed to the Carbon file manager API as being the most appropriate to use,  is this still true for modern OS X ?   ( I  understand Carbon might  soon depreciated totally ? )
>
> - I'm not looking to restart the threads on disk bandwidth but I  would really like to hear other people's experiences and get some tips before I start this project in earnest.
>
> Thanks in advance
> -Andy.
>
>
 _______________________________________________
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: Paul Davis <email@hidden>
  • Prev by Date: Re: AU embedded control never receives kEventControlDraw
  • Next by Date: Re: plugin development
  • Previous by thread: Re: AU embedded control never receives kEventControlDraw
  • Next by thread: Re: preferred disk api for high bandwidth sample reading
  • Index(es):
    • Date
    • Thread