• 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: Real-time buffer playback in Swift?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Real-time buffer playback in Swift?

  • Subject: Re: Real-time buffer playback in Swift?
  • From: Paul Davis <email@hidden>
  • Date: Wed, 17 Sep 2014 16:03:52 -0400


On Wed, Sep 17, 2014 at 1:09 PM, Zack Morris <email@hidden> wrote:
  Like context switches still take on the order of milliseconds.

12 usecs or less, actually, on a modern Linux kernel on not so fast hardware. But that doesn't include the effect of the TLB flush, which is variable as I mentioned.
 

I think on some level that the way computers perform context switching is wrong.  It probably won’t be fixed in typical UNIX kernels anytime soon, so I’m wondering if there’s a way to sidestep the kernel and somehow queue everything up to iron out the kinks of sleeping for so long.  I realize it probably isn’t possible when we need < 30 millisecond latencies for realtime audio processing.  But if CoreAudio can do it, then why have the separation between it and normal kernel processes at all?  I think it’s an honest question.

this is old research (like 1990's stuff). the answer is to use a single 64 bit address space and hardware that can mark page ranges as protected. the idea is to stop using address spaces as a means of providing protection from cross-process memory access. Look up (for example) the Opal operating system "concept".

when you do this, the whole notion of address spaces goes away (a pointer with address 0xfeedface can be passed around between processes, but they may not all be able to read/write it), which removes the need for VM hardware which speeds up context switching like crazy.

as i said, this is all old stuff that ran aground thanks to Microsoft and then Linux/Unix's utter domination of the OS marketplace. not much room left for deeply experimental kernels, and the ideas behind things like Opal can't easily be grafted onto the contemporary kernel of Windows, Darwin or Linux (or FreeBSD or whatever floats your boat)
 
 _______________________________________________
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: Real-time buffer playback in Swift?
      • From: Charles Constant <email@hidden>
References: 
 >Re: Real-time buffer playback in Swift? (From: Ian Kemmish <email@hidden>)
 >Re: Real-time buffer playback in Swift? (From: Zack Morris <email@hidden>)
 >Re: Real-time buffer playback in Swift? (From: Paul Davis <email@hidden>)
 >Re: Real-time buffer playback in Swift? (From: Zack Morris <email@hidden>)

  • Prev by Date: Re: Real-time buffer playback in Swift?
  • Next by Date: Connecting two kAudioUnitType_Effect nodes in augraph
  • Previous by thread: Re: Real-time buffer playback in Swift?
  • Next by thread: Re: Real-time buffer playback in Swift?
  • Index(es):
    • Date
    • Thread