Question

音频播放已在三星Galaxy S3和HTC One上成功测试，但在运行Android 4.4的LGE Nexus 4上严重受损。发生的事情是，可以在几分之一秒内听到非常精细的音频，然后是几秒钟的静音，接着是另一段短音频，然后是静音，所以它就会发生。因此，似乎音频流逻辑最终会在一个永恒的开始 - 播放 - 欠载 - 停止循环中结束。

我每隔一秒左右就会看到以下警告：

12-09 00:55:56.982  10842-14365/com.soundrop.android W/AudioTrack﹕ releaseBuffer() track 0x7b03f4e0 name=s:176;n:2;f:-1 disabled due to previous underrun, restarting
12-09 00:55:57.583  10842-14367/com.soundrop.android W/AudioTrack﹕ releaseBuffer() track 0x7b03f4e0 name=s:176;n:2;f:-1 disabled due to previous underrun, restarting
12-09 00:55:58.594  10842-14369/com.soundrop.android W/AudioTrack﹕ releaseBuffer() track 0x7b03f4e0 name=s:176;n:2;f:-1 disabled due to previous underrun, restarting
12-09 00:55:59.595  10842-14371/com.soundrop.android W/AudioTrack﹕ releaseBuffer() track 0x7b03f4e0 name=s:176;n:2;f:-1 disabled due to previous underrun, restarting
12-09 00:56:02.047  10842-14379/com.soundrop.android W/AudioTrack﹕ releaseBuffer() track 0x7b03f4e0 name=s:176;n:2;f:-1 disabled due to previous underrun, restarting

这让我想到设备之间可能的音频缓冲区差异，所以我做了一些探测：

HTC One (good playback): AudioTrack.getMinBufferSize(44100, STEREO, ENCODING_PCM_16BIT) => 16932
LGE Nexus 4 (bad playback): AudioTrack.getMinBufferSize(44100, STEREO, ENCODING_PCM_16BIT) => 7056

我的猜测是Deezer Android SDK在这个特定设备上设置了一个太小的缓冲区大小，因为它似乎选择的缓冲区大小是报告的最小大小的10倍。

更新：刚刚在运行4.4的HTC One上重现了音频卡顿，其中getMinBufferSize（）返回16932（就像在Android＆lt; 4.4上一样）。所以这个问题显然不是特定于设备的，而是与从KitKat开始的特定于操作系统的行为改变有关。

Answer 1

这确实是Android 4.4更新引发的问题。 AudioTrack实现中的某些内容已更改，并导致这些欠载问题。

我们目前正在努力解决此问题，我们会尽快发布。

带有Deezer Android SDK的LG Nexus 4上的永久音频卡顿

1 个答案: