Slashdot Mirror
The Android Lag Fix That Really Wasn't
jfruh writes "When Android was first introduced, it got much of its buzz in the open source community, and despite it being a mobile juggernaut backed by huge companies, it remains an open source project that anyone can submit code to. Thus, when a community patch that claimed to reduce the lag that still plagues the platform was created, it rocketed around various community code sites and was widely praised. The only problem: it didn't actually speed Android up."
The surprising thing, in both this Android case and the assorted car-widgets, is not that the placebo effect works; but that the "If it was that easy, why didn't it come from the factory that way" argument hasn't held more sway.
In the case of the 'vortex' device you link to, the argument is essentially that ~$1 worth of stamped metal could markedly improve the performance and fuel economy of most vehicles without other notable modifications. Short of a full-scale Petroleum-industrial-complex coverup, why aren't these things being bolted on at the factory?
In the Android case, it's not like entropy related issues are news to linux users or hardware makers. Devices that do lots of crypto(ie. network gear designed to support a lot of VPN users, http load balancers designed to serve a lot of SSL sessions, etc.) are frequently provided with dedicated hardware RNGs precisely to prevent performance issues on entropy depletion. VIA's more recent CPUs come with an on-die hardware RNG, and you can buy assorted RNGs for various expansion busses if your applications require it.
The issue isn't so much that you can entropy-starve a system and cause it to respond badly; but that(against a background of people already knowing that) Google went and released an OS that is somehow radically more demanding on /dev/random than most linux variants and didn't even notice? That would be a bit of a surprise.
The problem is that xda is full of this kind of crap. Kernels which disable fsync (libEAT-MY-DATA, anyone?), exotic I/O schedulers and CPU governors, overclocking processors and other hacks... Very often, they do not have any measurable effect, or even cause new problems, such as freezes, hangs, sleep of death,...
Having spent significant time with iOS devices, I can safely say that the notion that they do not lag is FALSE. Having just installed iOS 6 on an iPhone 4, the lag between just opening and closing basic applications is definitely noticeable. Hell, even my father's iPad 2 lags, and it runs on iOS 4!
My S2 Skyrocket, on the other hand, runs Jellybean 4.1.2 just fine, and cases of lag are rare, if any.
The fact is, all devices, get laggy with use, and your bias against Android makes you ignore the lag that the shiny animations of iOS induce.
There is no perfect, lag-free device.
You can't have 0 latency audio drivers. But the latency can vary from system to system due to design decisions.
The main source of latency in audio drivers is related on how many audio samples are generated for each call to the interrupt handler (buffer size).
Bigger buffer sizes help avoid gaps in audio due to interrupt jitter. They also reduce the CPU load and energy usage which are very important in mobile devices.
Driver infrastructer for very small buffer sizes need to be designed very carfully to work reliably. So there are many reasons why android developers decided not
to use very small buffer. BUT of course for any kind of interactive audio low latency is crucial.
I have nothing against Apple perse, but I have serious issues with the closed nature of their iOS devices and especially how I don't have the ability to control what gets transfered on or off the device. Everything has to go through iTunes or some cloud solution.
Android has no such restricting policies, that's why I'd like to see it 'win'.