音频播放已在三星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开始的特定于操作系统的行为改变有关.