• 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: "Ross Bencina" <email@hidden>
  • Date: Tue, 5 Jan 2010 17:38:31 +1100

Paul Davis wrote:
On Windows you can set flags to disable OS level caching/buffering when you
open a file handle (with the restriction of being required to perform IO in
page aligned blocks).

the same thing is possible with unix/posix APIs too.

Can you give some links/keywords please? What do you currently use in Ardour? read/write one buffer at a time using posix file io?



however, its not
clear to me that on machines with typically large chunks of RAM that
attempting to do your own thing is a win enough of the time to justify
doing it. in ardour, we work hard to chunk disk i/o into 256kB units
because we've found that this is roughly optimal with the filesystems
our users are mostly typically working with (optimal in the sense that
we get closer to the underlying hardware throughput).

Last time I benchmarked this on Windows (admittedly on older hardware, perhaps in the 1Ghz era) I saved about 10% CPU usage (from memory with 50-100 streams) by disabling the OS level i/o caching. It doesn't make much sense to incurr OS-level buffer copying and caching when a streaming-sepecific application level buffering/caching layer is needed anyway.



The other thing is to use some kind of
scatter gather i/o so that the OS level disk scheduler can queue up multiple
i/o requests with the disk so that the head path accross the disk can be
optimized.

my own preference is to assume that the disk scheduler can do the right thing without me having to work that hard :)

Except that unless the disk scheduler has multiple concurrent pending i/o requests it has no way to choose the best operation to perform first.



i've done some
fairly low level analysis of how various linux filesystems distribute
blocks across the disk during recording, and my conclusion has been
that its pointless trying to believe that i (as an app developer) can
predict the block layout.

That's not what I'm suggesting. I'm happy to leave that to the OS disk scheduler.


I'm just not sure what the best way is to queue multiple i/o requests to the scheduler on OSX. Posix AIO? multiple io threads? some kind of non-blocking ioctls? Mach async io (if there is such a thing).

Ross.





_______________________________________________
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>
    • Re: preferred disk api for high bandwidth sample reading
      • From: Jean-Daniel Dupas <email@hidden>
    • Where has the CoreAudio SDK gone?
      • From: Walt <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>)
 >Re: preferred disk api for high bandwidth sample reading (From: Paul Davis <email@hidden>)
 >Re: preferred disk api for high bandwidth sample reading (From: "Ross Bencina" <email@hidden>)
 >Re: preferred disk api for high bandwidth sample reading (From: Paul Davis <email@hidden>)

  • Prev by Date: Re: bastardizing AUEventListenerNotify() no longer working?
  • Next by Date: Where has the CoreAudio SDK gone?
  • Previous by thread: Re: preferred disk api for high bandwidth sample reading
  • Next by thread: Where has the CoreAudio SDK gone?
  • Index(es):
    • Date
    • Thread