Android 2.3.4, OpenSL ES y enorme log-spam por razones desconocidas

Una aplicación que he creado provoca extenso spam de registro en un dispositivo de un cliente:

Utilizo OpenSL en un entorno NDK para la generación de audio en tiempo real. Cada vez que uso la función Enqueue () de SLAndroidSimpleBufferQueueItf, android crea una entrada de registro porque esa llamada implícitamente llama a play () en la interfaz de audio.

Esto se ve así:

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

Esto es cómo Enqueue un nuevo búfer de audio a OpenSLES:

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

OpenSLES no se queja de esa llamada y devuelve SL_RESULT_SUCCESS.

Yo googled alrededor de un poco y encontró que la entrada de registro proviene de la fuente de Android AudioTrack, que he encontrado aquí:

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

Al principio de la función start () se encuentra el registro:

 LOGV("start %p", this);

¿Pero qué mantiene OpenSL para llamar a play () implícitamente cada vez que un nuevo búfer está en cola? He echado un vistazo en la especificación de OpenSL aquí: http://www.khronos.org/registry/sles/specs/OpenSL_ES_Specification_1.0.1.pdf

En la página 174 dicen: "Cuando el reproductor está en el estado SL_PLAYSTATE_PLAYING, que es controlado por la interfaz SLPlayItf [ver sección 8.32], la adición de búferes iniciará implícitamente la reproducción En el caso de hambre debido a la insuficiencia de búferes en la cola, de los datos de audio se detiene.El jugador permanece en el estado SL_PLAYSTATE_PLAYING.En la cola de búferes adicionales, la reproducción de los datos de audio se reanuda.Nota que la inanición de buffers en cola provoca huecos audibles en el flujo de datos de audio.En el caso en que el jugador no está en el estado de reproducción, la adición de búferes no inicia la reproducción de audio ".

Como el teléfono no está chispeando, asumo que el audio todavía está jugando muy bien y esta descripción de la documentación suena a mí como si SIEMPRE implícitamente comienzan la reproducción, que significa realmente que no hay ninguna ocasión para que prevenga este Spam del registro.

¿Algunas ideas?

IMHO que depende mucho y cambia de versión a versión de Android, de fabricante a fabricante ..

No estoy seguro de por qué el cliente final se molestó con el registro, pero sólo haría filtro en logcat para ignorarlo .. Simple solución es probablemente el mejor, especialmente cuando la fuente de spam está en el origen de Android: s

Principalmente depende del proveedor del dispositivo. Intente por favor en diverso dispositivo, y probablemente usted no verá estos registros, pero usted podría experimentar los diversos. No se puede hacer nada excepto agregar filtro a LogCat.