Suggestion that might reduce battery usage
Paul Wright 11 лет назад • обновлен Jona (Lead Developer) 11 лет назад • 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.
Сервис поддержки клиентов работает на платформе UserEcho
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.
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.