在我的一个项目中，我正在使用无尽流实现实况广播。我可以在没有任何问题的情况下使用原生的Android MediaPlayer，也可以在运行旧版Android的设备上使用，因为该流类型为audio/mpeg。我已经在运行1.6的HTC Magic上测试了它，并且它的工作完美无缺。即使在WLAN和3G之间切换时，它也只是缓冲起来，我只注意到一个小小的呃逆，然后继续播放，就好像什么都没发生过一样。它也很少断开连接，因为我在工作日期间一直在收音机中收听，并且在上下班的路上确保用户体验完全符合我的要求。对于运行Android 2.1的HTC Legend，HTC Wildfire 2.2以及运行2.2的三星Galaxy Tab等其他设备，我也重复了相同的步骤，结果相同。所有设备都能完美处理流。在HTC Desire上使用Android MediaPlayer进行流式传输时出现的奇怪行为Android 2.2
但是，这就是我在HTC Desire 2.2上遇到困难的地方，我有严重的问题让我玩这个游戏。使用MediaPlayer的标准实现时，即setDataSource（String path），它播放10 - 30秒，即使在WLAN和3G上都有完全接收时，它也会丢失连接。我已经尝试了不同的方法来解决这个问题，一个是使用NPR News项目的StreamProxy，经过一些修改后，它确实工作得很好。然而，HTC Desire仍然会不时断开连接，有时甚至会尝试重新连接4-5次，直到它实际上能够保持稳定的连接。
使用代理时，我得到的错误如下所示
08-08 09:35:17.810: ERROR/AwesomePlayer(67): Not sending buffering status because duration is unknown.
08-08 09:35:19.849: ERROR/HTTPStream(67): recv failed, errno = 11 (Try again)
08-08 09:35:19.849: INFO/HTTPDataSource(67): Retry ... 2 times left
08-08 09:35:19.849: WARN/HTTPStream(67): Calling connect()...
08-08 09:35:19.849: WARN/HTTPStream(67): Returned from connect()...
08-08 09:35:20.739: ERROR/(1576): Broken pipe
08-08 09:35:20.739: ERROR/(1576): java.net.SocketException: Broken pipe
08-08 09:35:20.739: ERROR/(1576): at org.apache.harmony.luni.platform.OSNetworkSystem.writeSocketImpl(Native Method)
08-08 09:35:20.739: ERROR/(1576): at org.apache.harmony.luni.platform.OSNetworkSystem.write(OSNetworkSystem.java:723)
08-08 09:35:20.739: ERROR/(1576): at org.apache.harmony.luni.net.PlainSocketImpl.write(PlainSocketImpl.java:578)
08-08 09:35:20.739: ERROR/(1576): at org.apache.harmony.luni.net.SocketOutputStream.write(SocketOutputStream.java:59)
08-08 09:35:20.739: ERROR/(1576): at org.jmvo.radio.StreamProxy.processRequest(StreamProxy.java:263)
08-08 09:35:20.739: ERROR/(1576): at org.jmvo.radio.StreamProxy.run(StreamProxy.java:138)
08-08 09:35:20.739: ERROR/(1576): at java.lang.Thread.run(Thread.java:1102)
，并直接使用的MediaPlayer时不使用代理
08-08 09:41:30.799: ERROR/AwesomePlayer(67): Not sending buffering status because duration is unknown.
08-08 09:41:32.849: ERROR/HTTPStream(67): recv failed, errno = 11 (Try again)
08-08 09:41:32.849: INFO/HTTPDataSource(67): Retry ... 2 times left
08-08 09:41:32.849: WARN/HTTPStream(67): Calling connect()...
08-08 09:41:32.870: WARN/HTTPStream(67): Returned from connect()...
08-08 09:41:33.160: INFO/HTTPDataSource(67): retrying connection succeeded.
08-08 09:41:34.839: VERBOSE/CacheingDataSource(67): partial readAt CachingDataSource::readAt(260221, 418):mSource->readAt(page<0xd0ff0>->mOffset 260416, mPageSize 1728)
08-08 09:41:36.839: ERROR/HTTPStream(67): recv failed, errno = 11 (Try again)
08-08 09:41:36.839: INFO/HTTPDataSource(67): Retry ... 1 times left
08-08 09:41:36.839: WARN/HTTPStream(67): Calling connect()...
08-08 09:41:36.859: WARN/HTTPStream(67): Returned from connect()...
08-08 09:41:37.361: INFO/HTTPDataSource(67): retrying connection succeeded.
一件事的。为了使该StreamProxy从NPR新闻工作真的很好，我不得不修改以这种方式使用它会导致气流中的连接松动每10以下行
byte[] buff = new byte[1024 * 50];
while (isRunning && (readBytes = data.read(buff, 0, buff.length)) != -1) {
client.getOutputStream().write(buff, 0, readBytes);
}
- 30秒。但是，当我将缓冲区大小降低到4字节甚至一个字节时，它的播放效果相当不错，尽管使用3G打嗝时经常发生，并且在重新连接时出现问题。
所以我的问题，没有人有任何想法与HTC Desires底层软件的交易是什么？我的意思是，它可以在运行相同版本OS的HTC Wildfire上完美运行。这两款设备的软件应该没有太大的区别？我也在多个HTC Desires上测试了这款应用程序，以确保它不仅仅是我的测试设备出现问题。但在其他设备上发生的问题与我在测试设备上的问题一样。
任何想法？
我有一个类似的项目，但目前我只使用MediaPlayer从v2.2默认缓冲。这不是你的意图，但是你的文章证明使用StreamProxy是值得的。 此外，您关于更改缓冲区大小的注意事项使我想到了这里发生了什么。看来MediaPlayer-default和StreamProxy-default都使用缓冲区，这些缓冲区太大并且会导致组块出现问题。 – Civilian
http://stackoverflow.com/questions/8671479/android-mediaplayer-works-fine-in-our-custom-audio-streaming-application-up-to-a –