我们遇到的几乎与这里提到的完全相反：为什么 Android 的 MediaPlayer 需要这么长时间才能准备一些直播流进行播放？
我已经测试了多个流，但特别是两个
1 - http://usa8-vn.mixstream.net:8138 - 采样率：32000Hz 和比特率：96 kb/s
2 - http://source01.platform02.true.nl:800 - 采样率：44100Hz 和比特率：128 kb/s
较低比特率的流立即开始播放（媒体播放器一开始播放prepared），而较高比特率的流最多需要两分钟才能开始播放。此外，当尝试流式传输我得到的更高比特率的流时MediaPlayer error (1, -110)（这应该是MEDIA_ERROR_UNKNOWN, 和MEDIA_ERROR_TIMED_OUT- 显然，因为加载某些东西需要很长时间）。然后，当我停止流时，我在 LogCat 中看到了这个：
05-22 20:26:13.625: E/MediaPlayer(23818): stop called in state 0
05-22 20:26:13.625: V/MediaPlayer(23818): message received msg=100, ext1=-38, ext2=0
05-22 20:26:13.625: E/MediaPlayer(23818): error (-38, 0)
...
05-22 20:26:13.645: W/MediaPlayer(23818): mediaplayer went away with unhandled events
我在Android 网站上找不到-38代码，所以我不知道那是什么。我也不确定是哪个状态。我假设是因为 Android 网站状态：state 0Idle
新构建的 MediaPlayer 对象与调用 reset() 后的 MediaPlayer 对象之间存在细微但重要的区别。对于这两种情况，在空闲状态下调用诸如 ... stop() ... 之类的方法是一个编程错误。
无论如何，关键是我不认为它像前面提到的链接所暗示的那样，因为较高的比特率应该比较低的比特率流更快地填充缓冲区，对吧？那么为什么启动流需要这么长时间呢？
附带说明一下，这在以下设备上运行良好：Samsung Galaxy Music、-Note、-Note II、-S II、-S III mini 和 Google Nexus 设备。正是在三星 Galaxy S III 上，我们才体验到从互联网上流式传输现场音乐的这种滞后性。
为什么？？