Android 2.3.4, OpenSL ES и огромный лог-спам по неизвестной причине

Одно приложение, которое я создал, вызывает обширный спам в журнале на устройстве клиента:

Я использую OpenSL в среде NDK для генерации звука в реальном времени. Каждый раз, когда я использую функцию Enqueue() из SLAndroidSimpleBufferQueueItf, Android создает запись в журнале, потому что этот вызов неявно вызывает play() на аудиоинтерфейсе.

Это выглядит так:

........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

Вот как я ставлю новый аудиобуфер в OpenSLES:

bool SE::AudioOutputOpenSLES::enqueueBuffer( void* _buffer, unsigned int _byteSize )
{
    SLresult result = (*bqPlayerBufferQueue)->Enqueue(bqPlayerBufferQueue, _buffer, _byteSize );

    return( result == SL_RESULT_SUCCESS );
}

OpenSLES не жалуется на этот вызов и возвращает SL_RESULT_SUCCESS.

Я немного погуглил и обнаружил, что запись в журнале исходит из исходного кода Android AudioTrack, который я нашел здесь:

https://android.googlesource.com/platform/frameworks/base/+/android-2.2.3_r2.1/media/libmedia/AudioTrack.cpp

В начале функции start() находится протоколирование:

LOGV("start %p", this);

Но что заставляет OpenSL неявно вызывать play() каждый раз, когда новый буфер ставится в очередь? Я просмотрел спецификацию OpenSL здесь: http://www.khronos.org/registry/sles/specs/OpenSL_ES_Specification_1.0.1.pdf

На странице 174 говорится: «Когда проигрыватель находится в состоянии SL_PLAYSTATE_PLAYING, которое управляется интерфейсом SLPlayItf [см. раздел 8.32], добавление буферов неявно запускает воспроизведение. В случае голодания из-за нехватки буферов в очереди воспроизведение аудиоданных останавливается. Проигрыватель остается в состоянии SL_PLAYSTATE_PLAYING. После постановки в очередь дополнительных буферов воспроизведение аудиоданных возобновляется. Обратите внимание, что нехватка буферов в очереди вызывает слышимые паузы в потоке аудиоданных. В случае, когда проигрыватель не находится в состояние воспроизведения, добавление буферов не запускает воспроизведение звука».

Поскольку телефон не трещит, я предполагаю, что звук по-прежнему воспроизводится хорошо, и это описание из документации звучит для меня так, как будто они ВСЕГДА неявно начинают воспроизведение, что фактически означает, что у меня нет шансов предотвратить спам в журнале.

Есть идеи?