I figure out something myself. I ran a crude experiment and my estimate to this delay is about 210 ms on my cell phone (Galaxy Epic) running Android 2.3.6.
Here is how I did my experiment: 1. I first modified a code sample of Chronometer and wrote a program to display a 1/100-second accuracy-timer. I ran this timer on another android phone. 2. My camera code handles the onPreviewFrame and pass the buffer to a GLSurfaceView object and map it to a 2D texture. This texture is updated for each call of onPreviewFrame. 3. I pointed the camera phone to the phone running the timer, and focus. 4. I used a DSLR, set exposure time to 1/100 second, and took a few shots with the timer running A sample photo can be found here: http://nmr.mgh.harvard.edu/~fangq/temp/androidcamera/frame_latency_test.jpg >From 8 shots, I removed 2 that showed overlapping digits. In the remaining 6, the mean delay is 208.3 ms with std=4 ms. I understand that this latency includes the OpenGL texture mapping, however, I suspected that it is small compare to the frame delay (otherwise, please correct me). I will test this on other phones and see if this is consistent on the 2.3.x androids. Qianqian On Apr 3, 2:12 pm, Qianqian Fang <[email protected]> wrote: > hi developers > > I am working on an android program to control an external hardware > and process camera images in the real time. The hardware interface > is an IOIO (http://www.sparkfun.com/products/10585). It controls an > LED array to turn on and off. The software captures images from the > camera > using setPreviewCallbackWithBuffer() and store a few image frames > per LED state. The camera thread and IOIO thread communicate > by wait/notify. > > Unfortunately, I found that the saved camera frames are not > synchronized > with the IOIO pin status; I can only get synchronized images when > I insert a Thread.sleep(delay>250) between toggling the IOIO pins > and signaling camera to start saving data. > > At first, I suspected that this was caused by the communication > latency on the IOIO side. But per IOIO's author, Ytai Ben-Tsvi, > this is way too long compared to the expected latency (1~4ms), see > > http://groups.google.com/group/ioio-users/browse_thread/thread/f81f05... > > If IOIO is ruled out, I now start questioning if there is > a delay when the onPreviewFrame() is triggered. > > Is there a way to quantify the latency of the onPreviewFrame > callbacks? > The surfaceview seems to get updated very quickly, but I don't know > how fast a displayed frame can be passed to onPreviewFrame() for > processing. > > Any android documents discuss about this? > > Qianqian -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
