8

音频播放已在三星 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 < 4.4 上所做的那样）。所以这个问题显然不是特定于设备的，而是与从 KitKat 开始的特定于操作系统的行为变化有关。

4

1 回答 1

1

这确实是 Android 4.4 更新提出的问题。AudioTrack 实现中的某些内容发生了变化，并导致了这些欠载问题。

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

于 2013-12-10T15:03:16.483 回答