One application that I created causes an extensive spam schedule on the client device:
I use OpenSL in the NDK environment to generate real-time sound. Every time I use the Enqueue () function for SLAndroidSimpleBufferQueueItf, the android creates a log entry because this call implicitly calls play () on the audio interface.
It looks like this:
........app start........ 06-05 21:36:48.619: I/System.out(10081): Debugger has connected 06-05 21:36:48.619: I/System.out(10081): waiting for debugger to settle... 06-05 21:36:48.819: I/System.out(10081): waiting for debugger to settle... 06-05 21:36:50.419: I/System.out(10081): waiting for debugger to settle... 06-05 21:36:50.619: I/System.out(10081): waiting for debugger to settle... 06-05 21:36:50.829: I/System.out(10081): debugger has settled (1491) // ....some other unimportant logging stuff was here .... 06-05 21:36:53.359: D/execute(10081): Creating audio output OpenSLES 06-05 21:36:53.369: D/AudioOutputOpenSLES(10081): Creating the engine 06-05 21:36:53.369: D/AudioOutputOpenSLES(10081): Realizing engine 06-05 21:36:53.369: D/AudioOutputOpenSLES(10081): retrieving engine interface 06-05 21:36:53.369: D/AudioOutputOpenSLES(10081): Creating output mix 06-05 21:36:53.369: D/AudioOutputOpenSLES(10081): Realizing output mix 06-05 21:36:53.369: D/AudioOutputOpenSLES(10081): Configuring audio source 06-05 21:36:53.369: D/AudioOutputOpenSLES(10081): Configuring audio sink 06-05 21:36:53.369: D/AudioOutputOpenSLES(10081): Creating audio player 06-05 21:36:53.379: D/AudioOutputOpenSLES(10081): realizing the player // Who is that? I assume Android itself.... 06-05 21:36:53.379: D/AudioTrack(10081): Request AudioFlinger to create track 06-05 21:36:53.379: D/AudioOutputOpenSLES(10081): Retrieving play interface 06-05 21:36:53.379: D/AudioOutputOpenSLES(10081): get buffer queue interface 06-05 21:36:53.379: D/AudioOutputOpenSLES(10081): registering buffer queue callback 06-05 21:36:53.379: D/AudioOutputOpenSLES(10081): Retrieving effect send interface 06-05 21:36:53.379: D/AudioOutputOpenSLES(10081): getting volume interface 06-05 21:36:53.379: D/execute(10081): First process call... 06-05 21:36:53.379: D/execute(10081): Will start playback 06-05 21:36:53.379: D/play(10081): Starting playback // And the show starts here: Every time I Enqueue audio data in my C++ code, this log entry appears. 06-05 21:36:53.379: D/AudioTrack(10081): start 0x1f7bf8 06-05 21:36:53.389: D/AudioTrack(10081): start 0x1f7bf8 06-05 21:36:53.409: D/AudioTrack(10081): start 0x1f7bf8 06-05 21:36:53.609: D/AudioTrack(10081): start 0x1f7bf8 06-05 21:36:53.629: D/AudioTrack(10081): start 0x1f7bf8 06-05 21:36:53.679: D/AudioTrack(10081): start 0x1f7bf8 06-05 21:36:53.739: D/AudioTrack(10081): start 0x1f7bf8 06-05 21:36:53.759: D/AudioTrack(10081): start 0x1f7bf8 06-05 21:36:53.819: D/AudioTrack(10081): start 0x1f7bf8 ....... and so on
This is how I introduce a new sound buffer in OpenSLES:
bool SE::AudioOutputOpenSLES::enqueueBuffer( void* _buffer, unsigned int _byteSize ) { SLresult result = (*bqPlayerBufferQueue)->Enqueue(bqPlayerBufferQueue, _buffer, _byteSize ); return( result == SL_RESULT_SUCCESS ); }
OpenSLES does not complain about this call and returns SL_RESULT_SUCCESS.
I did a bit of searching and found that the log entry comes from the Android AudioTrack source file, which I found here:
https://android.googlesource.com/platform/frameworks/base/+/android-2.2.3_r2.1/media/libmedia/AudioTrack.cpp
At the beginning of the start () function, it is registered:
LOGV("start %p", this);
But what holds OpenSL to invoke play () implicitly every time a new buffer is queued? I looked at the OpenSL specification here: http://www.khronos.org/registry/sles/specs/OpenSL_ES_Specification_1.0.1.pdf
On page 174 they say: “When a player is in the SL_PLAYSTATE_PLAYING state, which is controlled by the SLPlayItf interface [see section 8.32], adding buffers will implicitly trigger playback. In case of starvation due to insufficient buffers in the queue, audio data playback stops. The player remains in the SL_PLAYSTATE_PLAYING state. When additional buffers are queued, audio data resumes playing. Note that starving buffers in the queue causes audible gaps in the audio data stream. In the case when the player is not in a playback state, adding buffers does not start playing sound. "
Since the phone does not crack, I assume that the sound is still reproducing well, and this description from the documentation sounds to me as if they ALWAYS begin to implicitly start playing, which actually means that I have no chance to prevent this spam journal.
Any ideas?