StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POonPeriodicNotification() has the jitters on *some* devices
text
Body
copied!<p><strong>Why does onPeriodicNotification() behave so erratically?</strong></p> <p><strong>Background</strong><br> I'm working on an audio visualizer for Android that samples from the microphone using AudioRecord.read() (16-bit mono). I've done quite a bit of testing with sample rates and frame periods for setPositionNotificationPeriod(). In the end, I settled on:<br> <strong>Sample Rate:</strong> 8000<br> <strong>Frame Period:</strong> Sample Rate * 41 / 1000 = 328<br> <strong>Buffer Size:</strong> 5 * Sample Rate<br></p> <p>The frame period is 41 ms which I chose because I want ~24 frames per second for my visualizer. </p> <p>I thought that drawing to canvas at this rate would be a problem at first, but after testing on the DroidX and Nexus One, I was getting amazing performance. I can drop the latency to 20 ms on these devices without buffer-overruns but have no need to.</p> <p>Once I started testing on the Galaxy S and Nexus S, my performance tanked. This seemed odd since the Nexus S outperforms both devices by a large degree. After eliminating drawing and calculations as being the problem, I put timing calls in onPeriodicNotification(). I was able to confirm that the issue is due to this callback being called at willy-nilly time intervals and I do not understand why.</p> <p><strong>Creating a Fair Benchmark</strong><br> As a fair test, I took all of my audio processing and drawing out of the loop such that all my app does is read audio in a loop and log data in onPeriodicNotification(). I set the frame period to 100 ms and used the following timing code:</p> <pre><code>currentTime = SystemClock.elapsedRealtime(); Log.v(TAG, "time since last record update: " + (currentTime - lastTime)); lastTime = currentTime; </code></pre> <p>Finally, I sampled data for 5-minutes on each device. On the DroidX, I get about what I expect:<br> <strong># Points:</strong> 3008<br> <strong>Min:</strong> 92<br> <strong>Max:</strong> 105<br> <strong>Avg:</strong> 100<br> <strong>StdDev:</strong> 6.64<br></p> <p>This seems reasonable and I'm willing to live with this. On the Galaxy S, I get this:<BR> <strong># Points:</strong> 3004<BR> <strong>Min:</strong> 0!<BR> <strong>Max:</strong> 274<BR> <strong>Avg:</strong> 100.05<BR> <strong>StdDev:</strong> 126.30?!?<BR></p> <p>With a StdDev of 126, this means that a subsequent set of timing calls often looks like this [253, 0, 1, 258, 1, 0, 263].</p> <p><strong>Conclusion & other misc data</strong><br> While performing these tests, I kept an eye on CPU usage. My process hovers around 2-3% CPU usage with plenty of overhead to work with. I notice that if I increase the latency between notifications to around 250 ms, the Galaxy S begins behaving as I would expect (the stddev drops to around 6-7). Unfortunately, 250 ms is far from being a usable latency for audio visualization.</p> <p>After typing all this I can't help but feel this better belongs in some bug report, but then again this is Samsung we're talking about and we know they have <a href="https://stackoverflow.com/questions/4928267/where-to-report-device-specific-bugs-to-samsung">no internet android bug reporting presence</a> :(</p> <p>Alternatives, insights and experience are greatly appreciated.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload