title: Android-dev AudioRecord without blocking or threads
body: <p>I wish to record the microphone audio stream so I can do realtime DSP on it.</p>
  
  <p>I want to do so without having to use threads and without having <code>.read()</code> block while it waits for new audio data.</p>
  
  <p>UPDATE/ANSWER: It's a bug in Android. 4.2.2 still has the problem, but 5.01 IS FIXED! I'm not sure where the divide is but that's the story.</p>
  
  <p>NOTE: Please don't say "Just use threads." Threads are fine but this isn't about them, and the android developers intended for AudioRecord to be fully usable without me having to specify threads and without me having to deal with blocking read(). Thank you!</p>
  
  <p>Here is what I have found:</p>
  
  <p>When the AudioRecord object is initialized, it creates its own internal ring type buffer.
  When <code>.start()</code> is called, it begins recording to said ring buffer (or whatever kind it really is.)</p>
  
  <p>When <code>.read()</code> is called, it reads either half of bufferSize or the specified number of bytes (whichever is less) and then returns.</p>
  
  <p>If there is more than enough audio samples in the internal buffer, then read() returns instantly with the data. If there is not enough yet, then read() waits till there is, then returns with the data.</p>
  
  <p><code>.setRecordPositionUpdateListener()</code> can be used to set a Listener, and <code>.setPositionNotificationPeriod()</code> and <code>.setNotificationMarkerPosition()</code> can be used to set the notification Period and Position, respectively.</p>
  
  <p>However, the Listener seems to be never called unless certain requirements are met:</p>
  
  <p>1: The Period or Position must be equal to bufferSize/2 or (bufferSize/2)-1.</p>
  
  <p>2: A <code>.read()</code> must be called before the the Period or Position timer starts counting - in other words, after calling <code>.start()</code> then also call <code>.read()</code>, and each time the Listener is called, call <code>.read()</code> again.</p>
  
  <p>3: <code>.read()</code> must read at least half of bufferSize each time.</p>
  
  <p>So using these rules I am able to get the callback/Listener working, but for some reason the reads are still blocking and I can't figure out how to get the Listener to only be called when there is a full read's worth.</p>
  
  <p>If I rig up a button view to click to read, then I can tap it and if  tap rapidly, read blocks. But if I wait for the audio buffer to fill, then the first tap is instant (read returns right away) but subsiquent rapid taps are blocked because read() has to wait, I guess.</p>
  
  <p>Greatly appreciated would be any insight on how I might make the Listener work as intended - in such a way that my listener gets called when there's enough data for read() to return instantly.</p>
  
  <p>Below is the relavent parts of my code.</p>
  
  <p>I have some log statements in my code which send strings to logcat which allows me to see how long each command is  taking, and this is how I know that read() is blocking.
  (And the buttons in my simple test app also are very doggy slow to respond when it is reading repeatedly, but CPU is not pegged.)</p>
  
  <p>Thanks,
  ~Jesse</p>
  
  <p>In my OnCreate():</p>
  
  <pre><code>    bufferSize=AudioRecord.getMinBufferSize(samplerate,AudioFormat.CHANNEL_CONFIGURATION_MONO,AudioFormat.ENCODING_PCM_16BIT)*4;
          recorder = new AudioRecord (AudioSource.MIC,samplerate,AudioFormat.CHANNEL_CONFIGURATION_MONO,AudioFormat.ENCODING_PCM_16BIT,bufferSize);
          recorder.setRecordPositionUpdateListener(mRecordListener);
          recorder.setPositionNotificationPeriod(bufferSize/2);
          //recorder.setNotificationMarkerPosition(bufferSize/2);
          audioData = new short [bufferSize];
  
      recorder.startRecording();
              samplesread=recorder.read(audioData,0,bufferSize);//This triggers it to start doing the callback.
  </code></pre>
  
  <p>Then here is my listener:</p>
  
  <pre><code>public OnRecordPositionUpdateListener mRecordListener = new OnRecordPositionUpdateListener() 
  {
      public void onPeriodicNotification(AudioRecord recorder) //This one gets called every period. 
      {
          Log.d("TimeTrack", "AAA");
          samplesread=recorder.read(audioData,0,bufferSize);
          Log.d("TimeTrack", "BBB");
          //player.write(audioData, 0, samplesread);
          //Log.d("TimeTrack", "CCC");
          reads++;
      }
      @Override
      public void onMarkerReached(AudioRecord recorder) //This one gets called only once -- when the marker is reached.
      {
          Log.d("TimeTrack", "AAA");
          samplesread=recorder.read(audioData,0,bufferSize);
          Log.d("TimeTrack", "BBB");
          //player.write(audioData, 0, samplesread);
          //Log.d("TimeTrack", "CCC");
      }
  };
  </code></pre>
  
  <p>UPDATE: I have tried this on Android 2.2.3, 2.3.4, and now 4.0.3, and all act the same.
  Also: There is an open bug on code.google about it - one entry started in 2012 by someone else then one from 2013 started by me (I didn't know about the first):</p>
  
  <p>UPDATE 2016: Ahhhh finally after years of wondering if it was me or android, I finally have answer! I tried my above code on 4.2.2 and same problem.  I tried above code on 5.01, AND IT WORKS!!! And the initial .read() call is NOT needed anymore either. Now, once the .setPositionNotificationPeriod() and .StartRecording() are called, mRecordListener() just magically starts getting called every time there is data available <em>now</em> so it no longer blocks, because the callback is not called until <em>after</em> enough data has been recorded. I haven't listened to the data to know if it's recording correctly, but the callback is happening like it should, and it is <em>not</em> blocking the activity, like it used to!</p>
  
  <p><a href="http://code.google.com/p/android/issues/detail?id=53996" rel="noreferrer">http://code.google.com/p/android/issues/detail?id=53996</a></p>
  
  <p><a href="http://code.google.com/p/android/issues/detail?id=25138" rel="noreferrer">http://code.google.com/p/android/issues/detail?id=25138</a></p>
  
  <p>If folks who care about this bug log in and vote for and/or comment on the bug maybe it'll get addressed sooner by Google.</p>