+1
Under review

Suggestion that might reduce battery usage

Paul Wright 6 years ago • updated by Jona (Lead Developer) 6 years ago 4
I really like XiiaLive. It has been quite reliable, and it uses noticeably less battery power than one of the other popular radio apps (that app also caused strange phone behaviour, like lock-ups). Nevertheless, XiiaLive still uses more battery power than I would like, and maybe more than it needs to. I can download 80MB of podcasts in 2 minutes, for no noticeable battery usage, and play back a 3 hour podcast for just a fraction of my phone's battery life. Using XiiaLive for 2 hours, involving a similar amount of data download (though admittedly higher bit-rate processing during playback) will use up almost all of my battery. It occurred to me that one difference between XiiaLive and a podcast download with separate playback, is that the podcast download is probably receiving full/large data packets, while XiiaLive is reading the data as fast as it comes in from a throttled stream. That means the same amount of data will arrive in many many small packets, resulting in a lot more radio activity accessing the Wi-Fi network. I don't know how hard it is to do this in an Android App (I know how I'd do it on a PC), but one thing you could try, in order to increase the packet sizes, and thus reduce radio activity and battery usage, is to add a delay before reading the input stream. Figure out what percentage of your buffer equates to a full Wi-Fi/TCPIP packet, then add the corresponding delay. For example, if 10% of the buffer equals a good packet size, then don't try to read more data from the input stream until the buffer drops to 90% full (either calculate the required sleep time based on buffer fullness, or have the playback function trigger the read event at the 90% mark). Again, I don't know how hard it is, or if it's even possible, to do this using Android software (it depends how much control the software gives you versus how much it does for you automatically), but I have my fingers crossed for you.
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.
Thanks Paul for taking the time to write us about this! Well, I have tried multiple things to try to save on battery usage and definitively your assumption is on track.  I know I have previously tried a similar solution to what you have described but had brought some issues on some devices with buffering happening a lot.  However I am intrigued to try again.  I'll set it as planned.  By the way most of the stations on SHOUTcast are all TCP connections.
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.
+1
Officially longest post on this forum! :P

So yes android/java VM machine is doing something, I'm not sure exactly what with the network connection.  I need to look into it to try to understand how I could improve radio usage on the phone.  I definitively agree that constant radio usage does drain the battery.  I did however see a Google IO 2012 video, I believe, about the radio going to standby after a few seconds of usage.  If that's the case then it might be really hard to apply larger packets reads optimization idea.  I'll have to find that video to see what they are saying about the radio...