Android 2.3.4, OpenSL ES et log-spamming énorme pour une raison inconnue

Question

une application que j'ai créé des causes vaste log-spamming sur un périphérique d'un client:

J'utilise OpenSL dans un environnement NDK pour la production audio en temps réel . Chaque fois que j'utilise la fonction Enqueue() de SLAndroidSimpleBufferQueueItf, android crée une entrée de journal car cet appel appelle implicitement play() sur l'interface audio.

Cela ressemble à ça:

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

Voilà comment j'ENQUEUE un nouveau tampon audio à OpenSLES:

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

    return(result == SL_RESULT_SUCCESS); 
} 

OpenSLES ne se plaignent pas de cet appel et retourne SL_RESULT_SUCCESS.

Je googlé un peu et a constaté que l'entrée du journal provient de la source Android AudioTrack, que je trouve ici:

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

Au début de la fonction start() est l'enregistrement:

LOGV("start %p", this); 

Mais qu'est-ce qui empêche OpenSL d'appeler play() implicitement chaque fois qu'un nouveau tampon est mis en file d'attente? J'ai eu un coup d'oeil dans les spécifications de OpenSL ici: http://www.khronos.org/registry/sles/specs/OpenSL_ES_Specification_1.0.1.pdf

Sur la page 174, ils disent « Quand le joueur est dans l'état SL_PLAYSTATE_PLAYING, qui est contrôlé par l'interface SLPlayItf [voir la section 8.32], l'ajout de tampons commencera implicitement la lecture En cas de famine due à l'insuffisance des tampons dans la file d'attente, la lecture des données audio s'arrête.Le joueur reste à l'état SL_PLAYSTATE_PLAYING.Au moment de la mise en file d'attente de tampons supplémentaires, la lecture des données audio reprend. Dans le cas où le lecteur n'est pas dans l'état de lecture, l'ajout de tampons ne démarre pas la lecture audio. "

Comme le téléphone ne crépite pas, je suppose que l'audio est toujours en cours de lecture. icely et cette description de la documentation me semble comme si elles commencent TOUJOURS implicitement à démarrer la lecture, ce qui signifie effectivement qu'il n'y a aucune chance pour moi d'empêcher ce spam.

Des idées?

Answer 1

à mon humble avis qui dépend beaucoup et changements de version en version d'Android, du fabricant à l'autre ..

Je ne sais pas pourquoi le client final est dérangé par journal, mais je voudrais juste faire filtre logcat l'ignorer .. La solution simple est probablement la meilleure, surtout quand la source du spam est dans la source d'android: s

Answer 2

Cela dépend principalement du fournisseur de l'appareil. S'il vous plaît essayez sur un périphérique différent, et probablement vous ne verrez pas ces journaux, mais vous pourriez rencontrer les différents. Vous ne pouvez rien faire sauf ajouter un filtre à LogCat.