Your comments
As I have stated before, I should not have a dropout shorter than the duration of my buffers, but I do and therefore I don't believe the buffering is working. This is not an AAC thing, as I mostly listen to MP3 Shoutcast streams, including my own.
This has been occuring since around the time Sprint put in that proxy server, but of course, I have that set to 0.0.0.0 and have since a few days after they did it. Unfortunately I wasn't using XIiaLive much befor that, so I don't know if one has anything to do with the other or not. Just trying to feed you all I think may help solve the issue.
Jona,
I did the update yesterday and noticed the pre-buffer is 8 sec and the buffer is 8500 by default. I left these settings and in driving home, I noted a couple of stutters still. These are clearly occuring at bad handoff points, but if the buffers are working properly, it would seem that I would not have audio starting for less than 8 seconds after a dropout, which is not the case. I can invision that a dropout may occur for only a second and then the audio would return, but it should at least play for the length of the buffer, which it is not. It just appears that the buffer system is not working right. There is clearly a delay in the initial connecting with a stream, so it would appear that something is "buffering," but I don't know why this doesn't persist after the connection is made.
Once we're passed this issue, I'd really like another to be addressed, in regard to the PAD (program associated data) or ID Tag info... I hate how that shows up nearly 10 to 15 seconds ahead of the song actually playing! My automation systems don't send that out until the audio starts and for years I used Pocket Tunes on my Palm and never had that.
Scott
Customer support service by UserEcho