Google has verified that it is working to make changes so streaming audio services like Pandora and TuneWiki will no longer have poor quality while streaming over 3G. You geeky and curious types can check out the code changes for the framework at Android's git repository. No word on when to expect these changes, but Google has committed them into the Android source, so it shouldn't be too far off. Of course, this is going to depend on everyone from the manufacturer, the carrier, and maybe even the night janitor at the Pentagon to approve and build the changes, and then to distribute them.
When the tip about this came in, I jumped over to Google's Android bug tracker page and started reading. I was very curious, because I have no issues playing my music, either streaming or from my SD card. What I found upsets me slightly, and I'm going to rant a bit after the break. (Yes, I'm allowed to complain, too.) [Google Code via Android Central Forums]
Google has decided to switch to a different media framework, named Stagefright. I'm not sure why this change was made, but I'm thinking it has something to do with the Google Music service rumors that have been flying around. In any case, the change was made. It turns out that the way Stagefright is set up, certain file types (HE-AAC v1 and HE-AAC v2) no longer are decoded correctly. Big bug, right? Not so fast.
When you're streaming from Slacker (I'll be using them as an example, not singling them out) on WiMax or WiFi, everything sounds great, because it uses a higher quality audio codec to stream. But streaming over 3G (and EDGE -- I checked and it damn near killed me) sounds pretty poor. This is because they are using a lower quality audio codec -- see above -- when connected via cell data. Also, playing the cached "stations" from an app that are on your card can sound like crap as well, because they are cached in the lower quality format. Through reports from others, and my own tests, I can confirm that it works just dandy.
Here comes the ranting part.
There are two obvious choices here. The first is that application developers change their apps and use the higher quality codecs when streaming over a cellular network. This fixes the issue while streaming, both from the airwaves and from the SD card. The second is that Google goes back and supports legacy file types. Yes, legacy. The bad kind of legacy. The kind of legacy that adds in un-needed bloat, and when done often enough, affects performance. Why the hell are we going with the legacy solution? I can't play Leisure Suit Larry on a Windows 7 PC without some third party wizardry to support the older, worse performing bits left over from DOS 5 that the game depends on. All your PalmOS apps needed re-written to work with WebOS. Microsoft has all but abandoned Windows Mobile 6.5 application support in the upcoming Windows Phone 7. This is the right way to move forward. We pick on Apple a lot here (it's all out of love, Rene, I swear!), but Steve would never go backwards to appease software vendors, and neither should Andy.
I don't care if you call it a bug, a feature or a pony. It was done that way for a reason in the first place. Google even lists the new method as a feature of Froyo. Google does nothing without an eye towards the future, not because they love us, but because they don't want to waste money doing it twice. One of the commenters at the Google Code page about the issue has verified that the application vendors are unwilling to do anything about it, so Google will have to re-configure the OS to continue support for something they didn't want to support in the first place. Fix your damn apps, vendors. Don't force my favorite mobile OS to make changes and provide legacy support because you want to take the easy way out. Rdio works just fine, it sounds great, and they aren't causing a listed feature to be changed because they are lazy coders or want to go cheap on bandwidth. They just earned my 5 bucks a month.
Now feel free to tear me apart, but at least try to explain the benefit of changing everyone's software vs. developers changing their apps to keep up.
We may earn a commission for purchases using our links. Learn more.