title: OSX CoreAudio: Getting inNumberFrames in advance - on initialization?
body: <p>I'm experimenting with writing a simplistic single-AU play-through based, (almost)-no-latency <em>tracking phase vocoder</em> prototype in C. It's a standalone program. I want to find how much processing load can a single render callback safely bear, so I prefer keeping off async DSP. </p>
  
  <p>My concept is to have only one pre-determined value which is <strong><em>window step</em></strong>, or <strong><em>hop size</em></strong> or <strong><em>decimation factor</em></strong> (different names for same term used in different literature sources). This number would equal <code>inNumberFrames</code>, which somehow depends on the <strong><em>device sampling rate</em></strong> (and what else?). All other parameters, such as <strong><em>window size</em></strong> and <strong><em>FFT size</em></strong> would be set in relation to the window step. This seems the simplest method for keeipng everything inside one callback.</p>
  
  <p>Is there a safe method to machine-independently and safely guess or query which could be the <code>inNumberFrames</code> before the actual rendering starts, i.e. before calling <code>AudioOutputUnitStart()</code>?</p>
  
  <p>The phase vocoder algorithm is mostly standard and very simple, using vDSP functions for FFT, plus custom phase integration and I have no problems with it.</p>
  
  <h2>Additional debugging info</h2>
  
  <p>This code is monitoring timings within the input callback:</p>
  
  <pre class="lang-c prettyprint-override"><code>static Float64 prev_stime;  //prev. sample time
  static UInt64  prev_htime;  //prev. host time        
  printf("inBus: %d\tframes: %d\tHtime: %lld\tStime: %7.2lf\n",
         (unsigned int)inBusNumber,
         (unsigned int)inNumberFrames,
         inTimeStamp-&gt;mHostTime   - prev_htime,
         inTimeStamp-&gt;mSampleTime - prev_stime);
  prev_htime = inTimeStamp-&gt;mHostTime;
  prev_stime = inTimeStamp-&gt;mSampleTime;
  </code></pre>
  
  <p>Curious enough, the argument inTimeStamp->mSampleTime actually shows the number of rendered frames (name of the argument seems somewhat misguiding). This number is always <code>512</code>, no matter if another sampling rate has been re-set through <em>AudioMIDISetup.app</em> at runtime, as if the value had been programmatically hard-coded. On one hand, the </p>
  
  <pre><code>inTimeStamp-&gt;mHostTime - prev_htime
  </code></pre>
  
  <p>interval gets dynamically changed depending on the sampling rate set in a mathematically clear way. As long as sampling rate values match multiples of 44100Hz, actual rendering is going on. On the other hand 48kHz multiples produce the rendering <code>error -10863 ( =
  kAudioUnitErr_CannotDoInCurrentContext )</code>. I must have missed a very important point.</p>