Android 2.3.4、OpenSL ES和未知原因的大量日志垃圾邮件

我创建的一个应用程序在客户的设备上引发了大量的日志垃圾邮件：

我在NDK环境中使用OpenSL进行实时音频生成。每次我使用SLAndroidSimpleBufferQueueItf的Enqueue（）函数时，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源音频曲目，我在这里找到：

start（）函数的开头是日志记录：

LOGV("start %p", this);

但是，是什么让OpenSL在每次新缓冲区排队时都隐式调用play（）？我在这里查看了OpenSL规范：

在第174页，他们说“当播放器处于SL_播放状态时，由SLPlayItf接口控制[参见第8.32节]，添加缓冲区将隐式启动播放。如果由于队列中缓冲区不足而导致播放不足，音频数据的播放将停止。播放器将保持在SL_PLAYSTATE_playing状态。在对其他缓冲区进行排队时，音频数据的播放将恢复。请注意，队列缓冲区不足会导致音频数据中出现音频间隙ta流。在播放器未处于播放状态的情况下，添加缓冲区不会启动音频播放。”

由于手机没有发出噼啪声，我假设音频仍然播放得很好，文档中的描述听起来好像总是隐式地开始播放，这实际上意味着我没有机会阻止这种日志垃圾邮件

---

有什么想法吗？

我想这取决于安卓系统的不同版本，不同的制造商

---

我不知道为什么最终客户会为日志而烦恼，但我只会在logcat中设置过滤器来忽略它。。简单的解决方案可能是最好的，尤其是当垃圾邮件的来源在安卓系统的源中时：s

主要取决于设备的供应商。请在不同的设备上尝试，您可能看不到这些日志，但您可以体验不同的日志。除了向LogCat添加筛选器之外，您无法执行任何操作。

这将是筛选器

^（（？！AudioTrack）。*$

，它将忽略带有字符串AudioTrack的日志。