Related
http://www.anandtech.com/show/5630/indepth-with-the-windows-8-consumer-preview/1
Very LONG read, for those who haven't looked at it yet
But very well written. Not biased much at all. He brings up some good points, and makes very logical arguments.
I do want to point out one thing tho - almost every average joe PC user used a mouse as the sole input method, unless words need to be written, then you use the keyboard. As the author of the article pointed out, to use W8 with any type of efficiency you need to use either a touchscreen or lots of keyboard shortcuts. all of us tech geeks (and yes, if you're reading this, even if you're a noob that means you know exponentially more about tech than most people) are willing to learn and adapt, but most people don't even know that windows HAS keyboard shortcuts. it took me 20 minutes to understand hot corners 100%. how long do you think it'll take your tech illeratite mother to figure it out? a month? my mother still doesn't grasp how bookmarks in Chrome (which i installed for her so she could have an adblocked web) work, and she's had it for about 6 months.
point stands, yes, for us the learning curve isn't that bad. but for your average user off the street who doesn't know what a browser is (seriously, watch this http://www.youtube.com/watch?v=o4MwTvtyrUQ ) the learning curve is going to be too high to handle.
It is a well written article. To me the biggest argument is does it even matter for the average person to know all of the ins and outs of the start screen. As long as they can figure out how to click on the big icon labeled Internet, they can probably get to what they need. Once you're in the browser, metro is no longer applicable.
I think the basics are pretty easy to grab with minimal time on the system. So far I haven't had anybody NOT get it when I let them use it. Only a few minor questions at first which is normal for anything new.
Hmmm....
Well, the problem is that average users are very reluctant in breaking their old habits and often do not even WANT to learn something new. Unless something works roughly the same it used to before, they are not interested and write it off, because the "old one" was "so much better". I'm not saying all the people are like that, but a great deal really is, I used to work at tech support for quite a while and I think the video above is pretty accurate in terms of literacy in this field. People are very quick to write things off for the pettiest of reasons and 'interest' and plain curiosity fade fast.
I'm just wondering, with all the top devices now being on ICS or JB, or having updates in the near future, is there a conscious effort from developers to start recoding their apps in native code to keep them fast, bugfree and light? And if not, what would it take, as an online community to try to get them to do so?
Now, I am not a dev so I realise that anything I say here may be inaccurate, but to the best of my knowledge:
Most android apps are currently programmed in HTML5 or Java, both of which are easy to port and run on all android versions with the power to run them, as they have some kind of virtual emulator to run them, but that means they bottle-neck the phone, they run slow, they force close, these scripts are often buggy and unstable and they don't run or look as good/well as they should. This was great in early days when phones were slow anyways so you wouldn't notice the difference, but iOS and Android (and perhaps WP7, Rim and Symbian) apps would all get the same update in a relatively close timeframe and all be almost the same. In the current world of ultraphones such as the S3, iPhone 5 and Lumia 920, regardless of how you feel about their manufactureres or firmwares, are all powerful and fast phones, all capable of running native coded apps on the latest firmware versions and they are kick-ass all round. Now, native coded apps, as far as I'm aware, no longer need to be emulated, there is no program running to handle them, they are being read as if part of the system itself, kind of a synthetic arm attached to a person rather than a robot being operated by remote control (???), and therefore are faster and more efficient and if coded well, stable.
Apps currently seem to be the bottle neck on my s3, I can make the phone speed through the internet like there's no tomorrow, but if I open, for argument's sake, the YouTube app, it takes 2 or 3 seconds to open. The Facebook app (yes, Suckerberg has confirmed a native app for Android similar to the native iOS app for this one) is still kind of slow though I think it isn't as bad as people say. Lots of apps crap-out and die or load much slower than they should when 4 cores are pumping pure mobile testosterone into them, so we really need the boost.
A lot of iOS apps are natively coded now, they load up so fast on the 4S, and they are more reliable, which is a shame, because for obvious reasons I love the S3 much more but I find myself still reaching for the 4S for certain actions because I know that the apps will be ready quicker and wont decide they've had enough and die half way through use.
What do you guys, many of whom know more about this kind of stuff than me, have to offer in terms of this subject or what are your opinions?
This is specifically development related how? Wrong section.
OP, Please read the rules about posting and the proper places to post.
If you need to revisit the rules the link is in my sig. Please do NOT post non development threads in the development section.
Thread moved to general
Sorry, my logic was that 3rd party apps talk was to p do with developers and development, my apologies.
So, any answers?
There is a very simple reason to use Java for apps - write once run anywhere. If apps were native then they would have to be recompiled for every phone. In the Apple world this is not such a big problem but in the Android world this would soon become impractical. Your view on native vs emulated is not correct and probably a relic from Java version 1.0. Native apps do not necessarily run faster than Java apps and in most cases there is not difference in speed. People make a lot of assumptions that because its a virtual machine that it will be slow. The Davlik VM uses highly optimised byte code and is simply not the case. Most Android apps are UI and I/O bound and not CPU bound so you will not see any performance improvements by making them native. You mentioned loading times. Most apps are Odexed to optimise loading so its as fast as possible. Also bear in mind that many CPU intensive tasks are often handed over to specific chips i.e. graphics is handed over to the GPU e.g. a native call to OpenGL will be the same speed as a Java call to OpenGL. Games are the most CPU intensive apps you get on a phone but Android provides hardware acceleration pipelines to handover the workload to the GPU and not the CPU. So for significant majority of applications you will not notice a speed difference between a Java app and a native app and this applies to many other platforms and not just Android phones. This is of course not true for the kernel. Since that has to deal with multiple apps all accessing resources possibly simultaneously then that has to be as fast as it possibly can be. This is why the kernel is native but all of the apps that sit on it are not. Since there are a limited number of kernels usually one per version of Android, each manufacturer has no trouble porting that since that's much easier than porting millions of apps.
Also, your assumptions that non Java code is bug free is also not true. Apps in C/C++ are just as likely to have bugs in as Java code. In some cases they are more likely because you don't have to worry about memory management in Java because of the Garbage Collector in the VM. It sounds like you experienced some poor performing apps but this will be to do with poor coding and not because its written in Java.
So deploying apps in native code would be a major headache when when testing and debugging on multiple hardware platforms and the unlikely speed benefits of native are likely to not be visible to the end user. We would not have the rich world of apps on Android and multiple Android hardware vendors that we do today if apps were native.
I hope this answers your query.
dodgebizkit said:
I'm just wondering, with all the top devices now being on ICS or JB, or having updates in the near future, is there a conscious effort from developers to start recoding their apps in native code to keep them fast, bugfree and light? And if not, what would it take, as an online community to try to get them to do so?
Now, I am not a dev so I realise that anything I say here may be inaccurate, but to the best of my knowledge:
Most android apps are currently programmed in HTML5 or Java, both of which are easy to port and run on all android versions with the power to run them, as they have some kind of virtual emulator to run them, but that means they bottle-neck the phone, they run slow, they force close, these scripts are often buggy and unstable and they don't run or look as good/well as they should. This was great in early days when phones were slow anyways so you wouldn't notice the difference, but iOS and Android (and perhaps WP7, Rim and Symbian) apps would all get the same update in a relatively close timeframe and all be almost the same. In the current world of ultraphones such as the S3, iPhone 5 and Lumia 920, regardless of how you feel about their manufactureres or firmwares, are all powerful and fast phones, all capable of running native coded apps on the latest firmware versions and they are kick-ass all round. Now, native coded apps, as far as I'm aware, no longer need to be emulated, there is no program running to handle them, they are being read as if part of the system itself, kind of a synthetic arm attached to a person rather than a robot being operated by remote control (???), and therefore are faster and more efficient and if coded well, stable.
Apps currently seem to be the bottle neck on my s3, I can make the phone speed through the internet like there's no tomorrow, but if I open, for argument's sake, the YouTube app, it takes 2 or 3 seconds to open. The Facebook app (yes, Suckerberg has confirmed a native app for Android similar to the native iOS app for this one) is still kind of slow though I think it isn't as bad as people say. Lots of apps crap-out and die or load much slower than they should when 4 cores are pumping pure mobile testosterone into them, so we really need the boost.
A lot of iOS apps are natively coded now, they load up so fast on the 4S, and they are more reliable, which is a shame, because for obvious reasons I love the S3 much more but I find myself still reaching for the 4S for certain actions because I know that the apps will be ready quicker and wont decide they've had enough and die half way through use.
What do you guys, many of whom know more about this kind of stuff than me, have to offer in terms of this subject or what are your opinions?
Click to expand...
Click to collapse
Amazing answer.
Sent from an electronic device.
If your reaching for your 4s you should be on medication....
Sent from my GT-I9300 using xda premium
I don't buy that "native apps need to be compiled many times so it's a major headache" argument. The compilation can be done as a part of the deployment to store process. Play store knows the phone it installs the app on so can substitute a right executable. It can all be done behind the scene. Linux is C++ and yet is deployed on many various platforms.
Google should rather encourage people writing native code for performance critical applications rather than discouraging it, what they are doing now. Things like launchers, maps, browsers should be native. Java is often a lot slower than c++. If you want to see this try comparing map rendering in native and java in OsmAnd for example.
Adittionally, apps performing fast drain proportionally less battery, as they use less cpu cycles to do the same job. This is an important factor on mobile phones.
I've been professionally coding for 13 years both in c++ and java and have a good clue what I talk about. Also java coders tend to be less organized than c++ ones, which can explain the fact that we see more fc's on android than crashes on windows. A friend of mine likes telling "java is a language for programmers who cannot program".
"Smartphone is no longer a phone"
ahacker said:
Also java coders tend to be less organized than c++ ones, which can explain the fact that we see more fc's on android than crashes on windows. A friend of mine likes telling "java is a language for programmers who cannot program".
Click to expand...
Click to collapse
I call troll.
If you'd been a professional developer for 13 years you would know full well that both those statements are utter tosh.
Geoff (professional developer - not java - for 17 years)
Sent from my GT-I9300 using xda app-developers app
ahacker said:
Linux is C++ and yet is deployed on many various platforms.
Click to expand...
Click to collapse
If by "Linux", you mean the kernel then no. Linux is written in C. The GNU coreutils are also C. (Though the GCC people do want to make GCC a C++ program. But I digress.)
Sent from my GT-I9300 using Tapatalk 2
If you do raw speed benchmark tests to CPU intensive apps then a compiled app will always beat a VM app. Benchmarks do vary widely based on the type of benchmark and what compiler optimisations you turn on. This adds a complexity to your idea of letting the Play Store do the compilation. As a developer I'd hate to be in the situation that my compiled app worked fine on my phone and emulator but didn't work when compiled by the play store. How would you debug that? However despite native being faster the speed benefits are almost entirely hidden in most apps because they are interacting with the user, downloading from the web or offloading to the GPU. In my last mail I didn't even touch on security. Using a VM is a very neat way to give an app a limited security sandbox which is very secure.
I think you're maybe being a little harsh on Java programmers. You get good and bad programmers in any language. I think the reality is with a language as open as Java you get more "have a go" programmers which can result in some very dodgy apps on the Play Store. However, the developers of the core Android apps do not fall into this category and its the core apps that we really care about here.
I myself have over 20 years experience coding an Java, C/C++ and a variety of different platforms but rather than descend into a Java vs C++ war and focus back on the original question. The efficiency gains using native are not enough to warrant having to support native apps. If they were, a tech savy firm like Google would have done it. I think the security, support and deployment advantages far outweigh the performance gains for most applications. Sure there would some parts of a few apps that may benefit from the optimisation that native would provide but to facilitate native development Google would have to provide two APIs. Instead Google has ONE platform for all apps, theirs and everyone else's which is very sensible. If Google had to support a native API and a Java API then the doubles the support and development work which would increase time to market and increase cost. For a commercial company the right solution is always a balance between the right technical solution and practicality and cost considerations.
Marsbar said:
I call troll.
Click to expand...
Click to collapse
I call an aggressive idiot, who instead of arguing against my points attacks me personally.
"Smartphone is no longer a phone"
ahacker said:
I call an aggressive idiot, who instead of arguing against my points attacks me personally.
Click to expand...
Click to collapse
If you really think that was a personal attack you have some issues.
To come to a developers forum that is likely to have a high proportion of java developers and say that about them is a troll, pure and simple. If you want to prove otherwise then make an argument that makes any sort of sense.
Quality developers develop quality code whatever language they use. I've worked on quality codebases in VB6 of all things and I've worked on C++ from supposed professionals that made my brain spin from the mess.
Sent from my GT-I9300 using xda app-developers app
Then what is the advantage of native coding?
dodgebizkit said:
Then what is the advantage of native coding?
Click to expand...
Click to collapse
These days, when the majority of app time is io and memory bound and when things like graphic manipulation is handled by the graphics chips or (failing that) by tightly optimized native libraries, far less than you might think, especially since dalvik (the android jvm) comes with a just-in-time compiler that effectively turns java bytecode into native code. Any advantage there might be is rarely worth the extra development time required.
People like Mozilla are perhaps the exception in that they have a huge amount of investment in legacy code that would cost a fortune to redevelop. But for a new app, there's little obvious advantage.
Sent from my GT-I9300 using xda app-developers app
I've got a question... Any plans to implement the new Android-friendly Bluez stack recently rolled out? Seems it would fit with your open-source goals pretty nicely, while also providing enhanced functionality over the status quo...
Sometime last year there were several reports of a successful PulseAudio port as well. As I recall, it offered performance and feature enhancements, though the final word I've seen on the port was a sort of an open-source compromise because the port still required interaction with the closed-source HAL.
Anyway, it seems to me that successful inlines of the above projects might even be incorporated at least in part upstream, thereby setting you apart in your contributions, your feature set, and helping to offload some of the work for both sides.
Also, I want those things.
-Mike
mikeserv said:
I've got a question... Any plans to implement the new Android-friendly Bluez stack recently rolled out? Seems it would fit with your open-source goals pretty nicely, while also providing enhanced functionality over the status quo...
Sometime last year there were several reports of a successful PulseAudio port as well. As I recall, it offered performance and feature enhancements, though the final word I've seen on the port was a sort of an open-source compromise because the port still required interaction with the closed-source HAL.
Anyway, it seems to me that successful inlines of the above projects might even be incorporated at least in part upstream, thereby setting you apart in your contributions, your feature set, and helping to offload some of the work for both sides.
Also, I want those things.
-Mike
Click to expand...
Click to collapse
Well, the existing Android bluetooth stack is also open source, so the question would be what this "new" BlueZ stack (which isn't new, Android used BlueZ for years and switched away with 4.1 or 4.2, can't remember...) offers.
For audio - We have open HALs for a lot of devices, and for those devices we don't have an open HAL for, pulseaudio won't really help.
Entropy512 said:
Well, the existing Android bluetooth stack is also open source, so the question would be what this "new" BlueZ stack (which isn't new, Android used BlueZ for years and switched away with 4.1 or 4.2, can't remember...) offers.
For audio - We have open HALs for a lot of devices, and for those devices we don't have an open HAL for, pulseaudio won't really help.
Click to expand...
Click to collapse
But the existing Bluetooth stack is Android specific, whereas Bluez is a standard Linux component. It's also just recently made itself more Android friendly and (arguably) provides a better documented, more standardized interface.The same can be said of PulseAudio versus Android's sound daemon; implementing either or both would provide for more ease of interoperability between Android and other Linux devices, diminish Android fragmentation, and relieve some of the strain imposed by redundant development. What's more, I think both of these goals are probably largely achievable, but I was just asking.
Also, I want those things.
-Mike
mikeserv said:
But the existing Bluetooth stack is Android specific, whereas Bluez is a standard Linux component. It's also just recently made itself more Android friendly and (arguably) provides a better documented, more standardized interface.The same can be said of PulseAudio versus Android's sound daemon; implementing either or both would provide for more ease of interoperability between Android and other Linux devices, diminish Android fragmentation, and relieve some of the strain imposed by redundant development. What's more, I think both of these goals are probably largely achievable, but I was just asking.
Also, I want those things.
-Mike
Click to expand...
Click to collapse
Well, BlueZ was the default Android stack for quite some time - it was dropped for whatever reason. So not sure why they need to make it more "android friendly" when it was part of Android for a few years.
As to PulseAudio - it's a consistent bane of my existence on the desktop, and is probably overkill for mobile.
Of course, if you want to take a crack at integrating them and actually find that they do have tangible benefits, give it a try!
Entropy512 said:
Well, BlueZ was the default Android stack for quite some time - it was dropped for whatever reason. So not sure why they need to make it more "android friendly" when it was part of Android for a few years.
As to PulseAudio - it's a consistent bane of my existence on the desktop, and is probably overkill for mobile.
Of course, if you want to take a crack at integrating them and actually find that they do have tangible benefits, give it a try!
Click to expand...
Click to collapse
Wow. Strong words. You consider PulseAudio an existential bane, huh? Can I ask what sound daemon you use instead? I suppose it's possible you do without. Though it seems OSS is entirely deprecated, ALSA can still provide minimal functionality without a user-space management daemon if necessary, but without some extensive and, at least to me, seemingly esoteric initial configurations, good luck handling even a lasting volume adjustment without root access (or be in the "sound' group, I suppose), and should you have occasion to simultaneously offer two applications sound privileges... Sorry, grinding my teeth again.
Anyway, I didn't much like PA at first either, but I wanna say my first encounter with it was Ubuntu 7.10 or so, or thereabouts. I've since adopted the greener pastures offerred by several other distributions, less brown anyway, but PulseAudio is a fairly static component of my sound system as configured by default by distro maintainers no matter where I wander. Even on systems I build up myself from very little, when PulseAudio is included it tends to be one the things I have to consider least as trouble goes. The plugin support is very extensive these days as well.
When PulseAudio is combined with Bluez for instance, it can emulate almost all of the headset profiles, to include a telecommunications headset, and can easily record from this stream or any other because every one of PA's sources can be easily multiplexed. It's fun, and very powerful. PA can do on cheap or even no dedicated hardware at all what Airplay only aspires to. And these days, it even makes it easy. It's a true sound server, and while it can be utilized simply enough with Android satellite clients if you set it to emulate Airplay, to serve a multi/unicast, and/or to emulate the DLNA protocol, even this impressive scope of functionality is much diminished when compared to two PA servers working in concert.
Other desktop alternatives do exist, of course. There's Jack, designed to provide low-latency, realtime audio rendering, but these days it seems it too seems to operate best, and is most often configured to do so by default, in conjunction with a PA daemon. And MPD of course, which I confess I have much interest in, but very little other incentive otherwise to actually try for myself. I don't actually known what it's capable of. Perhaps you do? I wonder, is it just, as is eponymously implied, a music player daemon? Or can it actually be extended to do the kinds of things I've come to expect of PA as hinted at above? I really should find out.
Anyway, if you haven't had a look at this, it might interest you: http://arunraghavan.net/2012/01/pulseaudio-vs-audioflinger-fight/
The author takes care to provide many impressive benchmarking results as proof of the worth of his efforts. If that sparks your interest, you'll find the Android port homepage here: http://www.freedesktop.org/wiki/Software/PulseAudio/Ports/Android/.
And try to remember that PulseAudio is a more mature and proven project than is Android itself, much less SoundFlinger, and each of these three could be said to have experienced some rather rocky starts.
As for the Bluez project being recently dropped from Android and its even more recent Android-focused development, I believe these things are likely just as related as they appear to be. I would have to dig deeper than scanning a few kernel changelogs to be sure, but as I understand it for about a year or two, Bluez has been undergoing a codebase overhaul. I expect that in such a scenario the Linux kernel's default Bluetooth stack would have to focus initial efforts on the Linux kernel's core x86 support, and especially providing ARM support would prove difficult due to its lack of a default firmware interface and handling the myriad hardware access mechanisms might just have been too much at the time. Again, these are my assumptions, but what has definitely happened recently is a concerted effort at full Android support. If my assumptions are correct, then probably the Bluez project just got caught up is all. In any case, the functionality Bluez provides, especially where networking transparency is concerned, is definitely superior. Find out for yourself if you'd like to know.
Surely I'll find out for myself soon, as I guess i'll be diving in after all. Never built Android from source before, which doesn't make much sense as I've had nothing but Android devices since my G1, every one of which, up to and including the Dream, was rooted and flashed with at least a replacement recovery pretty much on day one. I guess better late than never, though.
Back soon, I expect! Best wishes!
-Mike
I still use it because I really don't want to spend all the time ripping it out and replacing it with something else on my Ubuntu machines, but it consistently fails to operate properly on nearly every machine I have. It's way too complex and the end result is that it breaks all the time.
That said, because of my experiences with it, I will never personally put any effort into putting it into more places. It is in too many already.
*edit of this mistakenly resulted in double-post below*
Entropy512 said:
I still use it because I really don't want to spend all the time ripping it out and replacing it with something else on my Ubuntu machines, but it consistently fails to operate properly on nearly every machine I have. It's way too complex and the end result is that it breaks all the time.
That said, because of my experiences with it, I will never personally put any effort into putting it into more places. It is in too many already.
Click to expand...
Click to collapse
Maybe that's true, but if you asked me I'd probably lean the other way and say instead that Ubuntu is in too many places. Honestly, PA is really not complicated if you consider it a suite of core sound apps as opposed to a single, cohesive application. Probably my biggest gripe with Ubuntu's interfaces is that they often do the opposite, which is of course contrary to Unix principles, and in the process they tend to sort of opaque over simple and accessible modular designs.
I won't attempt to argue that PulseAudio is simple by design, as we both know I'd be certain to lose that argument, but it does offer a few lesser known interfaces you might find interesting. For instance, one of my favorite little tools is pacat. This does exactly what it sounds like; point it at one or more of PA's sources and it will concatenate their raw audio output into stdout at which point you are free to pipeline it as you would any other stream. Imagine you took pacat, perhaps also lz4, nc, and another little pipe-friendly PA tool called paplay directed at a PA sync on its system rather than a source, and combined them all into a pipeline. I hope in this you might begin to see some of PA's merits that perhaps you've missed before.
Also, there is pacmd, which is not nearly as straightforward as those others I've mentioned, but is far more capable and very well documented. It can do anything PA can do, really, and is fully scriptable.
I don't know which versions of Ubuntu you use, but those not on rolling releases may not yet have caught up to the PA update that implemented a PulseAudio-module-specific udev adaptation. Newer PA versions now pretty much auto-configure audio modules in the same way early user-space handles kernel-module loading. It's kinda cool, and almost an entirely hands-off process.
Anyway, I'm through proselytizing. I just thought I'd mention these things because they're the bits that I use when I want to do something with it.
EDIT:
Entropy512 said:
...because of my experiences with it, I will never personally put any effort into putting it into more places...
Click to expand...
Click to collapse
I looked again and noticed this. While I fully understand where you're coming from here, I thought I heard some French kid on YouTube say that this was not the sort of response that should be expected for OmniRom feature requests. He described a sort of democratically driven road map, and specifically he said that if a feature request was well enough supported by the users, then the developers would implement it even if they did not agree it should be done. Has this policy changed?
Of course I realize that youtube guy was probably talking about majority rule as opposed to a well-argued request, and that I'm only one person, but above you say you will never do this thing, without making any allowances for the possibility of a vote or poll or similar.
Like I say, I fully understand your position on this, as I, of course, do not intend to devote my own efforts to something like further Android fragmentation for instance, vote or no vote. I just wish to know what to expect here, and if maybe I missed something.
-Mike
Everyone on the project are volunteers. Time is a limited resource, and we tend to prefer working on things we enjoy since we're not getting paid for it.
There's a big difference between "I have no interest whatsoever in working on this myself" and "I hate this so much I will mercilessly -2 it without any discussion". The latter is what I've promised never to do.
If someone's going to implement a feature, I'm OK with that as long as it doesn't have significant negative impacts (which PA would likely have, but I'll give it the benefit of the doubt...), I'll even give them some tips/assistance.
However, given the pain and suffering I went through with the yamahell audio HAL, touching audio again if I don't have to is dead last on my priorities list.
Looking at your link - it seems like nearly any advantage PA might have would only be seen by commandline clients - All apps would have to be presented with something that is "audioflinger-like" which didn't offer the extra features offered to clients. Also, PA claims improved power consumption - but they actually likely do not support LPA or tunnel mode.
To me it looks like PA offers a huge integration effort for little to no actual benefit.
Also, that article was written in January 2012 - I can tell you for certain that Google made MAJOR changes to the audio setup with Jellybean in mid-2012 including the ability to select buffer configurations that are use-case-dependent - https://github.com/omnirom/android_...210153d8f19a0ca825b33f2282b9ae071c6ec#diff-11
Entropy512 said:
Everyone on the project are volunteers. Time is a limited resource, and we tend to prefer working on things we enjoy since we're not getting paid for it.
There's a big difference between "I have no interest whatsoever in working on this myself" and "I hate this so much I will mercilessly -2 it without any discussion". The latter is what I've promised never to do.
If someone's going to implement a feature, I'm OK with that as long as it doesn't have significant negative impacts (which PA would likely have, but I'll give it the benefit of the doubt...), I'll even give them some tips/assistance.
However, given the pain and suffering I went through with the yamahell audio HAL, touching audio again if I don't have to is dead last on my priorities list.
Click to expand...
Click to collapse
Wow, man! Thanks very much indeed for replying with honesty and humility. I'm very pleased that I didn't, or at least I hope I did not. Even if you had said otherwise I would have fully understood, of course, but as it is, I'm also very impressed. I like discussion. Thanks, man.
Two questions: what's yamahell? And, because you say you've worked with it, can you tell me about AudioFlinger or whatever it is and maybe why the status quo is desirable? I thought it was a problem. I'm asking these things for my own edification and because I think I'm gonna try something to do with a PA replacement.
While I agree PA may be overkill, I really don't believe pulse has to be applied monolithically, you know? It's already designed to work with modules, so maybe a subset would be sufficient. Clients only communicate with libpulse.so for the most part, for example. And for the past few months (on an upstream system) PA and Bz have been working really well together. So I'll try it, maybe, after you tell your horror stories and I can judge for myself.
-Mike
-
Entropy512 said:
Looking at your link - it seems like nearly any advantage PA might have would only be seen by commandline clients...
Click to expand...
Click to collapse
I assume you mean the first one, the blog on the initial port? Well, I believe that may have changed since then. The actual port homepage at freedesktop.org (the second link I provided) says this:
Code:
...[T]ested on Samsung/Google Galaxy Nexus as ... reference implementation... [P]ort fairly straight-forward for ... devices with ALSA support.
Various bits of functionality are available, and this is a moving target. The following are tested at the time of writing this section:
Audio playback for most apps using native Android APIs
Volume control
Switching of outputs depending on the device plugged in (headphones, headset)
To Be Done
The following pieces are either partially or not at all implemented
Audio playback API completeness: infrequently-used bits of the API (loops, markers, etc.) are not implemented
***BIG ONE*** Calls: this is work-in-progress, but needs to be cleaned and merged
Policy: initial implementations of volumes and port switching are done. There are probably a lot of bits of policy that still need to be implemented for us to have feature/bug-parity with standard Android.
Audio record API: can be implemented fairly easily like the playback API was
***NOT CLEAR ON THIS*** Audio effects API (we don't support this in PulseAudio at the moment)
Entropy512 said:
Also, PA claims improved power consumption - but they actually likely do not support LPA or tunnel mode.
Click to expand...
Click to collapse
Something tells me this is a statement I should be able to fully comprehend before getting neck deep...
Entropy512 said:
To me it looks like PA offers a huge integration effort for little to no actual benefit.
Click to expand...
Click to collapse
It doesn't look so huge to me, as much is already done, I think. But then I've to hear your horror stories so I will reserve judgement.
Entropy512 said:
Also, that article was written in January 2012 - I can tell you for certain that Google made MAJOR changes to the audio setup with Jellybean in mid-2012 including the ability to select buffer configurations that are use-case-dependent - https://github.com/omnirom/android_...210153d8f19a0ca825b33f2282b9ae071c6ec#diff-11
Click to expand...
Click to collapse
Yes, that article was written then, but the freedesktop.org homepage was created March of this year. I suspect some changes have accumulated along the way, and because PA is an actively developed high-profile application hosted and backed by RedHat, I expect that website landing page would be removed soon after it became irrelevant. I will, of course, reach out to the maintainers at that end as well for advice.
But... that's kind of the point... less redundancy, you know? Less fragmentation? No need for separate groups for thisnkind of stuff. I just thought that was inline with omni ideals. Is there another way that you know of that could as easily bring a like convergence of functionality with other Linux systems? I just wanted to effect something along those lines and I thought omni sounded like a place worth starting.
Also, I want those things.
-Mike
P.S. This is the git repo described in the .XML repo definition for the PA build-code at freedesktop.org: http://cgit.collabora.com/git/
You can see the android specific PA packages are being worked on, and very recently. Also, ALSA is seeing somewhat recent dev work as well.
EDIT: This may not even be quite as difficult as i initially assumed.You can also see at the following git repo that a commit was made to master referencing 'mako' 5 weeks ago.
http://cgit.collabora.com/git/android/platform/external/collabora/pulseaudio-android.git/
yamahell - the hell that was working with the Yamaha MC1N2 codec seen on many Galaxy S2 family devices.
Poorly documented, kernel code written by a member of a primitive tribe with no concept of zero, Samsung's blob HALs doing all sorts of unpredictable crap requiring workaorunds and hacks...
One of the things that the Android audio subsystem has (overall) great support for is hardware accelerated decoding of compressed audio. LPA and tunnel mode are both methods for doing hardware accelerated audio decoding even when the host CPU is asleep.
The closest analog to this in the PC world would really be AC3 passthrough to an external decoder - which happens to be where 90% of my hatred of PulseAudio comes from. Its usual response to AC3 passthrough switching on/off is to screw up the audio codec and do weird stuff like pass AC3 through but not set the "this is a bitstream and not raw audio" bit, or send raw audio when setting the "this is a compressed bitstream" bit.
Entropy512 said:
...no concept of zero...
Click to expand...
Click to collapse
....should I?
Entropy512 said:
One of the things that the Android audio subsystem has (overall) great support for is hardware accelerated decoding of compressed audio. LPA and tunnel mode are both methods for doing hardware accelerated audio decoding even when the host CPU is asleep.
The closest analog to this in the PC world would really be AC3 passthrough to an external decoder - which happens to be where 90% of my hatred of PulseAudio comes from. Its usual response to AC3 passthrough switching on/off is to screw up the audio codec and do weird stuff like pass AC3 through but not set the "this is a bitstream and not raw audio" bit, or send raw audio when setting the "this is a compressed bitstream" bit.
Click to expand...
Click to collapse
This makes very good sense. While I think the PA 4.0 changeligs from July or so may acknowledge this lack they also seem to indicate it's been addressed. Would you mind looking? Not positive I'm reading it right.
-Mike
I have been somewhat following the whole Phonebloks and ARA scene, participating in the Dscout missions, and generally have to say that there is a lot of buzz and hype with very little meat behind it. The general populace is thinking legos, colors, fancy shmancy materials, and other appearance related nonsense. There seems to be very little technical content, and the majority of the crowd seems to be lured by key words such as "eco", "reusable", "repairable", "customizable" and so on.
Certainly, in terms of driving sales, this is good attention, something Motorola needs.
The downside, however, seems to be that people do not understand how things work, have no patience for it, and want things to "just work."
I highly doubt that this will be something that is user friendly out of the box.
The biggest misconception seems to be that you will be able to build anything you want out of this. If this idea is not curbed, this project will fail. People will become disappointed. Already they seem to think that they can have an espresso maker and a telescope added to the thing.
On top of it all, Motorola has a track record of taking good ideas and executing them poorly. Think Atrix lapdock.
So what is the clear mission of this project?
Ease of repair? That can already be done using current production methods. Look at the iPhone vs Galaxy series in terms of screen replacement. Its night and day.
Reusing parts? What could you reuse from an iPhone 4 when building a 5s? The headphone jack? Batteries die, radios, memory, sensors, processors, become old news by the time they hit the assembly line, and screens evolve at a fast pace.
There is no mention of a core device with expansion bays, the project seems to suggest you could swap all basic components on the fly. This is nonsense. Is it really worth taking steps back to make separate little bricks for Bluetooth, Wifi, NFC, GSM radio, etc., when current production methods can squeeze these into a single system-on-chip design at a fraction of the cost?
Imagine for a minute if Googorola took the Moto X approach to hardware: You log into your Motomaker account, and at checkout you pick your options. 3 choices of screen size, 3 choices of processors, 3 choices of storage capacity, an 8, 13, or 16 Mpix camera, 3 different battery capacities, cdma, gsm, or global radio, etc., then once you select your hardware, you customize the case colors, and you're done.
I know this rant is way into the TL;DR territory, but there are other factors to consider, perhaps profitability being paramount. Open source phone, with open source modules, etc. How will Motorola make $ on this? How long till knock off modules hit the market? What is the pricing scheme, etc.
I would love to get a serious discussion going, touching on some of the things I brought up.
Sent from my Nexus 5 using xda app-developers app
I wouldn't say they're doomed from the start but their social network app and stuff seems pretty gimmicky to me. I definitely think that modular phones are in the future but they need to spend more time talking about the actual hardware and open sourcing drivers and stuff instead of their weird Instagram clone in my opinion. I'm still staying optimistic if they don't do it someone else will.
Sent using Tapatalk
Nice idea, but people here at xda would have a nightmare with such a thing, meaning rom development for every and each component combination.......
Lets ask ourselves, when would it be appropriate or papamount to upgrade a hardware component of any of our phones now? The reasoning now is more like, 'it would be cool if we could'. I cant think of any necessary reason now for needing to change harware unless it needs repair. I believe necessity should be a starting point for this whole concept. Necessity often drives truly good design.
I personally think that this would be good because of the fact that technology advances at such a rapid pace that being able to upgrade your components when a better version comes out would be good. Obviously there would be some compatibility issues between some parts that would be unavoidable. It would be more for the person who wants the high end device. Take me for example, I have the S4 and I love it but next year when the S5 comes out it wouldn't be the latest and greatest and I can't upgrade for two years. I could love a Moto X but I don't wanna pay the off contract price for it. So I think this is the only time it would be good and efficient, not a huge game changer but a slight game changer.
Also about the knock off or cheap parts, if they have the drivers and protocols open source than it shouldn't be to big of an issue, not anymore than buying a knock off replacement screen. Still something to look out for when buying modules.
I think that the idea from Phoneblocks or Ara are really good but I think that the project will prospere
Project Ara.
Being a modular design, brings complications, but with those complications comes new opportunities in the hardware section as well as the software side of the development.
The metric is quite valid and tangible, even more so today, wth the manufacturing techniques available, this idea actually makes far more sense than feeding the giant a steady diet of the same old thing.
You save money if all you require is a modified version of the RF section, you install that block.
The same goes for the remainder of the phone, easy upgrading, no downtime, and lower overall cost for the entire market, not to mention the lowering of landfill garbage from dumped devices that could not be upgraded.
The engineering end of this is wonderful, I wish it arrived years ago. A 'Lego-Phone' you build and upgrade as you need to, no more buying an aircraft carrier, when all you require is a shuttle.
We can finally drive the market, provide for ourselves, push manufacturers in the direction we need them to head, instead of driving us with their own thoughts on what is necessary.
I don't use much in the way of media, so anything more than 720P is of little use, but I do appreciate an HDMI-type format screen.
The RF section is far more important to my needs, and of course, a micro-SD card slot.
I prefer a sensitive front end, high dynamic range, and a superbly augmented IP3(third intercept point) as a basis for my receiver design.
I have grown tired of matchbox quality RF systems, and when in poor signal areas, or in a heavily wooded area with sparse cell tower penetration, i prefer my phone have the ability to connect with a site even if the RSSI indicates no signal, at least a data channel should be able to 'hear' a short text message for help if sent.
If the phone can't hear well, it can't talk well, either.
Most subscribers assume that cell signals are routed through the power lines*!*
I have had customers that actually said this...But this is the basis of my most desired and important 'want', a solid RF system, receiver and transmitter section that works!
High density areas have few problems with dropped calls, if the site loading is low, but in rural areas, loading is not an issue, it's accessibility, and sites spaced 10 miles apart, can actually have users drop calls even near by, due to dense foliage or hilly/mountainous terrain, even though the tower is within eyesight, you still drop a call. This is where fresnel zones come into play, and where a good RF section makes the difference.
If you think rain kills RF signals, see my pic I just snapped from my door, of the trees filled with heavy snow!
Poorly designed RF systems can't decode signals properly, the B.E.R suffers, causing message failures, call time-outs as well as just lousy QOS due to noise, echoing, raspy speech processing and a host of other problems.
The memory subsystems are important, as well as the GPU and video systems, but you can still make a call if the video drops, not so much if the RF section dies.
We all have our own desires, as well as what is most important to our needs, but overall, i do believe that project Ara is a great step in the right direction for a change....Where the customer drive the market, not the manufacturers!
Now I don't know if you were aware, but Google only owns Motorola's Research Lab. The actual company was purchased by Lenovo a few weeks ago.
Besides, I sort feel the same way, because, besides the hubbub, it doesn't seem like a very user friendly process in my mind. That's why I think it feels like nothing more than a research project with a couple of news reporters locked inside their facilities.
Sent from my ST21i using XDA app-developers app.
Don't forget to hit thanks if I helped!
In the beginning, they will have to offer options in a controlled environment like one poster abive said. It will be similar to
1. CHOOSE YOUR PROCESSOR:
a. Good
b. Better
c. Best
Etc etc....
The first question probably will be "Choose Your Carrier". Then all of the module choices will be pre-screened to function together on that network.
Samsung Galaxy S4 "Fort Knox Edition"
Guys, believe in Google. They made a search engine wich is now the most used engine. They also made a very good browser, an operating system for mobiles, an online map wich has street view and many other good things. Why they couldn't make project ara?
Sent from my LG-P880 using xda app-developers app
PenguinStyle said:
Guys, believe in Google. They made a search engine wich is now the most used engine. They also made a very good browser, an operating system for mobiles, an online map wich has street view and many other good things. Why they couldn't make project ara?
Sent from my LG-P880 using xda app-developers app
Click to expand...
Click to collapse
Just making sure it wasnt a misinterpretation but google did not create android, Android Inc founded by andy rubin(correct me if im wrong) http://www.techradar.com/news/phone...e-phones/a-complete-history-of-android-470327
PenguinStyle said:
Guys, believe in Google. They made a search engine wich is now the most used engine. They also made a very good browser, an operating system for mobiles, an online map wich has street view and many other good things. Why they couldn't make project ara?
Sent from my LG-P880 using xda app-developers app
Click to expand...
Click to collapse
All those things you mention are software, that runs on high performance computers. What ARA requires is a total rethinking of the hardware and engineering of today's mobile phones.
Can any module be swapped for some other type of module? How do they interface? What bandwidth limitations do these interfaces introduce?
Sent from my GT-I9505 using Tapatalk
SynGates said:
All those things you mention are software, that runs on high performance computers. What ARA requires is a total rethinking of the hardware and engineering of today's mobile phones.
Can any module be swapped for some other type of module? How do they interface? What bandwidth limitations do these interfaces introduce?
Sent from my GT-I9505 using Tapatalk
Click to expand...
Click to collapse
The ARA developers conference already answered most of this, so its possibility is not the question. Its availability and adaptability is the question. Will people flock to it or despise it?? Will it make people feel more in control?
If google can advertise this thing as something that gives people more power it will definitely catch on. Plus if Google is truly looking to start their own mobile network as rumoured, then they could start in that manner and make others envious to catch on.
Sent from my SM-G900T using Tapatalk
It's going to be a wait and see what happens on release thing I think. I don't personally don't think it's going to explode instantly onto the mobile scene but give it a year or two and hopefully it will start changing the game. With everything being open source it might pave the way for smaller companies to get into the handheld scene where they don't have the money or resources to develop full devices but can focus on just a single module. Much like the way of the custom pc market.
replicamask said:
It's going to be a wait and see what happens on release thing I think. I don't personally don't think it's going to explode instantly onto the mobile scene but give it a year or two and hopefully it will start changing the game. With everything being open source it might pave the way for smaller companies to get into the handheld scene where they don't have the money or resources to develop full devices but can focus on just a single module. Much like the way of the custom pc market.
Click to expand...
Click to collapse
My sentiments exactly.
Koreans will really fight against this project. They won't be willing to loose the cellular market to Google. ARA has a lot of potential in developing countries, provided the prices for modules will be adequate. But yes, even with adequate pricetag such innovation will require a drastic change in marketing-infected minds of people.
Sent from my SM-N900W8 using Tapatalk 4
I hope it could work really well. I'd like to see the ability to transfer all the core modules from one endo 'frame' to another - SIM, WiFi, ROM, storage plus camera and perhaps CPU/RAM from a larger 'everyday' frame to a smaller 'night out' frame. I'd like an 'everyday' camera and a 'holiday' camera. I might carry a speaker module, but would swap it in against a torch module only for those occasions I'd need it. I'd carry spare battery modules and expect to see external chargers for them.
Didn't read the whole thread, but I'd say the whole "eco friendly" concept is BS from the beginning. People will start buying new components everytime they are out, thus generating MORE electric waste.
till22 said:
Didn't read the whole thread, but I'd say the whole "eco friendly" concept is BS from the beginning. People will start buying new components everytime they are out, thus generating MORE electric waste.
Click to expand...
Click to collapse
This is possible and a good point. I think they could counter this by placing some inherent value on modules so you could trade them in for cash or credit towards other modules.
I think this will work much better than trading in phones since all modules should work for all ara phones.
What you all need to remember is that the microcomputer revolution didn't really become a mass market phenomenon until the IBM PC arrived with its open "Industry Standard Architecture". This allowed the rapid emergence of third party expansion cards and other "PC compatible" hardware, and "PC clones". Not only did this accelerate the pace of technology development it also pushed prices down significantly. If IBM had not made the PC architecture both expandable and open, general purpose computing would have remained an expensive and specialised tool available only to business and the very rich. Imagine the effect that wouls have had on the development of the worldwide web a decade later.
If you are of the generation who grew up uaing laptops you may not have realised that modular technology is cheaper and more flexible, and it means longer hardware lifecycles.
This, coupled with samsung 7.0 memeory overflow bug?
Thoughts?
It will happen if a skilled enough coder wants it to. Row Hammer plus memory overflow, sounds like an attack vector for sure. Especially with an Eng Kernel/Rooted Device.
The fact that a method has not been made public means one of two things, A.) The people capable enough don't care about spending the effort when they probably have a google device. Or B.) The method has already been concocted, but it is being kept secret for data mining purposes. Like the Vault7 programs.
But it is good to know that Row Hammer has an entrance.