我们正在经历与这里提到的几乎完全相反的情况：为什么 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, and 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
我找不到-38上的代码安卓网站，所以我不知道那是什么。我也不确定是哪个州state 0。我假设Idle因为 Android 网站声明：
新构造的 MediaPlayer 对象与调用 reset() 后的 MediaPlayer 对象之间存在细微但重要的区别。对于这两种情况，在空闲状态下调用诸如 ... stop() ... 之类的方法都是编程错误。
无论如何，重点是我认为这不像之前提到的链接所建议的那样，因为较高的比特率应该比较低的比特率流更快地填充缓冲区，对吧？那么为什么要花这么长时间才能开始直播呢？
顺便说一句，这在以下设备上运行得非常好：Samsung Galaxy Music、- Note、- Note II、- S II、- S III mini 和 Google Nexus 设备。仅在三星 Galaxy S III 上，我们就遇到了从互联网流式传输现场音乐的延迟。
Why??
