Thank you for the response, and for your attention to this issue. I know that it's complex, given that you have no idea what you're going to be dealing with in terms of network, wi-fi hardware, or phone hardware. I can't say that I'm surprised that you ran into buffering issues in your past attempts to make improvements in this area. Your situation is more complex than any networking problem I've had to face, in my limited experience.

I guess if I was going to try this, I would: 1. Introduce a delay or lag time; 2. Make the time an advanced user configuration setting (say up to two seconds); 3. Default the time to zero, so it works the same as today; 4. In the description for the setting, state that it should be set back to zero if there are any problems (to try to save yourself extra support requests); 5. Initially wait the "delay time" after filling the buffer and before starting to play the music, to force buffering upstream; 6. Subsequently, try to read the input stream in 1/2 "delay time" bursts (e.g. if the delay time is 2 seconds, then every 1 second, read 1 second's worth of music data).

Of course, as you already know, there is no guarantee that this will work as desired, even if you can avoid the (possibly hardware-dependent) buffering problems you described. As I said before, I have no idea what the Android VM is doing for you under the covers. Then there is the fact that both TCP, and the underlying network, have formulas to control message sizes, in order to fairly share the network. And then there's the even more technical stuff that I've never had to play with, like the TCP "maximum segment size" parameter. And finally, even if you manage to finesse the network into sending larger messages, there is still the question of how the phone manages the power to its wi-fi circuitry, and whether it might thwart your efforts.

But I don't want to be negative. I applaud you for trying to make improvements in this area in the past, and I look forward to anything you can do in the future.

I have one other idea, which is to try to convince the larger Internet music providers (like SHOUTcast) to provide a burst-mode data stream. This has probably been suggested before, but the situation has changed. There would have been little motivation to do it in the past, when dealing with PCs. It only becomes an issue when dealing with battery-operated devices, like cellphones. Instead of a steady stream, if the music provider were to transmit the music data in, for example, one minute high-speed bursts, then, for the cellphone, it would be more like downloading a podcast file, and should result in lower power usage.

I must say that I am impressed with the way i see you responding in this forum. It is a reflection of the quality I perceive in your product. Thanks again.

Rats. I've been thinking about it, and my suggestion above is probably wrong. My experience is with TCP over Ethernet, where the bytes are transmitted in order, and blocking can take place. The podcast download in my example probably uses TCP.

But it occurred to me that radio streaming probably uses UDP, where the data packets can arrive out of order, and only the final receiver puts them back together (I've never used UDP, so I'm going on memory from two decades ago). Thus, delayed reading will have no effect on UDP packet size.

So now the only question is how Wi-Fi transmits the data, and whether it can be encouraged to transmit more data per radio transmission. I don't know the answer to that, but hopefully you do.

Feel free to delete this whole thread if the idea turns out to be ridiculous.

On the plus side, I thought of an easier way to force upstream buffering without having to introduce a delay timer or event into your own code. That would be to simply wait a bit longer after you initially fill your buffer before you first star playing the music. But, that's probably moot because, as I said, a delay in reading UDP probably won't have the desired effect.