It's not about performance, it's about content. And, if you have seen the amount of Games and Apps available at launch for the Ouya, it's quite spectacular. But hey, the PS3 and 360 specs are quite disappointing by todays standards also. Besides, you've all had a year to study this, being surprised of the performance is ignorance and laziness; in which case we probably don't want you developing for it anyway.
I am sorry but as the developer of RetroArch (an app where we NEED relatively good audio and video latency to maintain any kind of decent audio-video synchronization), I can tell you that you couldn't be more wrong about this.
Originally Posted by dalingrin
Android is an absolute piece of garbage for any kind of realtime app - the audio latency is so bad that it makes the PS3's 40ms audio latency on the audio server seem almost 'low latency' by comparison.
Please stop perpetuating this 'myth' that Android is 'just fine' for games or realtime apps - it is not - it is a bad, sad joke, and iOS/QNX makes absolute mincemeat of it.
Find me one guy that has something favorable to say about Android from a performance standpoint compared to iOS/QNX- you can't find one because the thing can't be defended. It was the absolute worst idea on Earth to base an OS (INTENDED FOR A MOBILE PLATFORM) around some piece of garbage Java VM which has a bad habit of eating RAM like no tomorrow (minimum RAM requirements for Android 4.2.2 are now 768MB RAM - FOR A MOBILE OS!!! This is absolute insanity).
Oh BTW - since you mentioned OpenGL - I should mention to you that the OpenGL side is also written in Java - as is the audio side (AudioFlinger) -as is the input side (InputEvent service) - as is everything on this goddamn piece of garbage OS. And guess what? Everything you do (whether it is some stupid innocuous weather app - written in Java - or whether it is this crappy OpenGL implementation in Java - or whether it is the crappy audio subsystem) CAN AND WILL at any time invoke the Dalvik garbage collector - and guess what that does to your performance?
Oh BTW - I saw somebody saying that XBMC 'runs just fine on my Android phone' - no it doesn't - the audio lag is terrible and it pretty much makes any movie you play unwatchable. Try XBMC on iOS however and be amazed at how well it runs by comparison.
And no, I am not employed by Apple - I don't like Apple's restrictions either - but it's an inconvenient truth that Apple - despite the douchebaggy company it is - has their shit together on the technical side while Google doesn't. I'd expect the badly amateuristic hack that is Android to emerge from some startup company - NOT from a multibillion dollar company that struts around like it owns the world (ie. Google) while pretending it can do no harm.
Oh BTW - please do 'debate me' on this - I'm looking quite forward to seeing you defend the absolutely terrible runtime performance that this piece of garbage - Android - delivers to developers who are actually going to the effort of writing non-managed code for it - it will be quite amusing to see the amount of denial about this particular piece of crapware.
Last edited by Squarepusher; 04-16-2013 at 09:28 AM.
Maybe the ubuntu phone OS will fix that for us since it is developed in C/C++ so no intermediary JIT or VM needed to execute instructions.
Originally Posted by Squarepusher
Those are good points - the one about RPi stands out to me, because today you can get something like the MK802 II for about the same price and probably triple the performance while being a smaller device. RPi, IMO, is great for what it was intended for, which was NOT media stuff and XBMC. I feel a little bad for the devs of RPi because people just blindly bought it thinking "oh I'll just make a media PC out of it" not realizing that it isn't going to be very good at that, and then people start trash talking about it because it isn't some high-end performer that they somehow expected of it. These are the same people who want 512MB of RAM and SATA and all that stuff. Some people really don't understand why things cost the way they do.
Originally Posted by uid313
For the record, RPi was intended for education and development. That being said, it's hardware is more than sufficient.
My Pivos plays and runs XBMC just as fine as any of my iOS devices (all however are far better performing the Raspberry Pi which is running linux). So much for your theory, as that statement is pure BS. Perhaps you saw a version of XBMC running on an android device that did not have any acceleration support.
Originally Posted by Squarepusher
I'm sorry but you are either lying or you can simply not tell the difference between the iOS version or the Android version based on some technical inability to perceive the very clear differences.
Originally Posted by deanjo
The Android version can never be as good as the iOS version because of the disastrous and totally dogshit audio latency that is STILL an issue to this day (no, the 'OpenSL fast mixer' path was only for one phone - and even then it still pales in comparison to CoreAudio on iOS). It can also never be as good as the iOS version because of the simple fact that you don't have a Java garbage collector that is hellbent on trashing your runtime performance at a periodical basis (make that every 5 minutes if you're running Google's crapware Play Store services as they seem to like to rely on the garbage collector - 'memory management' is soooo '90s, as is performance apparently). How are you likin' those 20 to 50ms garbage collector stalls?
So please - come up with some real performance figures and don't com with your 'appeal to authority - I am a moderator so I can make a vague claim like 'My Pivos plays and runs XBMC just as fine as any of my iOS devices' - that tells us exactly nothing. Notice I actually provided details and facts as opposed to 'my Pivos just runs XBMC fine' - you might want to start upping your game in that department if you want to have any hope of winning this argument. So much for 'pure BS' and who exactly is putting that into practice.
Lastly, to the moderator I'd say -
if you are not a dev, then your opinion doesn't count. The ground rules are very simple - if you are not a dev, you don't have a frame of reference on any of this. Period. I don't care if you can run a benchmark or not - that does not make you knowledgeable on anything.
Once you become a dev, you can start grasping what an absolute unmitigated disaster a garbage collector is to your average runtime performance (especially when said OS puts you inside a Java VM as your 'jail').
Last edited by Squarepusher; 04-16-2013 at 12:45 PM.
I haven't tackled anything android yet, but how much can you jam into the NDK to avoid java and GC? I do realize this is inferior to just doing it in c++ (or c). You would hope google would in the future provide a way for developers who care to totally avoid java where control and performance matters.
Originally Posted by Squarepusher
Well, the 'native activity' is kinda a misnomer - what it is, is just 'glue code' so that your native code (compiled as a dynamic shared library) can interface with Android's lifecycle system through a bidirectional pipe. This means that your native code is actually running on a secondary Java thread and that it has to continually send interprocess communication calls to to the main Java thread that it is still alive. If it doesn't respond to any disputched input events for instance within 5 seconds, then the main Java thread assumes that your program got unresponsive and it will issue an 'ANR' (Application Not Responsive) and will ask you to kill it.
Originally Posted by bnolsen
Anyway, a 'native activity' is just some kind of hack therefore where your native code compiled as a library (and interfaced through JNI) can work in your Java app. However, none of the 'NDK API' functions are actually native code - the OpenGL NDK code just tallks to the OpenGL Java service which in turn talks to Binder IPC. For audio, OpenSL still talks to AudioFlinger which is a Java service. Same with input - the NDK actually prevents you from reading from /dev/input/event directly - everything has to go through InputEventService and the Java side 'pumps' the input to your native code and you just need to 'react' to it.
Anyway, a 'native activity' is not 'real' native code - there are still a hundred and one possibilities for any of these upper layers to trigger garbage collector stalls - and these can range from 2 to 20 and even 50ms. What is even worse is that you have no control over 'services' that might be running concurrently with your app - for instance, if the lovely email service decides it needs to check your mail every five minutes while you are playing a game, then you are going to get pummeled with lovely garbage collector stalls that can ruin your framerate. Worse still, the worst offenders that I have logged turns out to be services like Google's Play Store services and there is absolutely no way to turn those periodic scan intervals off. In the end you walk away with the sense that Google cares more about datamining everybody's ass than they care about giving you any decent kind of runtime performance.
Anyway, for apps where you need realtime tight syncing, Android is an absolute disaster and you're just better off going with iOS/QNX - sad but true but it is really quite bad. We can only hope that ARM Linux starts getting somewhere even if it means having to interface with Android GPU driver binary blobs - already the memory requirements are insane (768MB for Android 4.2.2) and that is bound to increase as they keep piling more and more frills eye candy stuff onto this thing. It is simply an ill fit for a mobile OS and they just got the entire thing backwards - it is so bloated it should really be centred around desktop computers and even then nobody would want to deal with it.
Latency is not an issue with video playback. AE takes care of the timing and keeping it in sync with the video. Furthermore, when working with passthru audio it become nearly a non-existent issue. This is further more backed up by XBMC's own statistic counter which accurately displays AV sync errors. Latency for video playback is a non factor in most scenarios. Where it would come into play is would be realtime mixing with recording, again not an issue with playback. Garbage collector stalls are also easily overcome with a proper playback buffer.
Originally Posted by Squarepusher