The Cortex A7 is still king in powerful wearable SoCs today: Snapdragon 400, Exynos 3250 and MediaTek MT2601. These are still capable enough to run a full Android or equivalent smartwatch OS, but do not compromise on heat-up and empty the small batteries they're coupled with.
+ARM just announced the highly successful Cortex-A7 successor, the ARMv8 64-bit Cortex-A35. It's described at being better at everything than the A7 and also configurable. SoC vendors will be able to choose which or customize the blocks included without resorting to build their own CPU: something very convenient to scale it from IoT devices choosing it instead of micro-controllers to full-fledged smartphones.
We will probably see it as small core in big.LITTLE configuration as well, since the A53 has not been as convincing as hoped.
+Sam Pullen demonstrates in this video the main limitation with Google's current computational photography approach.
Reported by most reviewers as "lag" or "bugs" of the #Nexus 5X and 6P camera app since this is the mode activated by default, it has a simple explanation: The amount of time to process multi-exposures shot as one HDR+ picture joined with the limited amount of RAM allowed as buffer makes it unsuitable for consecutive pictures shooting.
Here's the process which occurs with any Android smartphone since the past few years:
– you launch the camera app – the viewfinder preview starts the ISP to capture full resolution readouts from the sensor at 30 FPS, renders them at near display resolution, adjusting in real-time automatic exposure and white balance – you press the shutter button – the camera ISP hardware takes one of the full resolution sensor readout, renders it in full resolution, compresses the output automatically using the hardware JPEG encoder, offers the compressed file as a buffer to the camera app, camera app saves it as a file on disk. – the previous sequence of operations, using almost no CPU at all can be repeated at 4 times per second or more.
Instead, here's the process with HDR+:
– until you press the shutter button: identical. – the camera ISP hardware takes multiple (up to 9*) consecutive readouts, some with positive and negative exposure compensation, from the sensor at 30 FPS, renders them and offers them as uncompressed buffers in RAM to the camera application. – the camera application takes all these images as input and feeds them to a super-resolution algorithm, which also tunes the local contrast and color balance, compressing or extending the dynamic range locally depending on the analyzed image content. – the HDR+ algorithm takes a few hundred milliseconds to several seconds to render a processed image – once the HDR+ algorithm is finished, it offers the result as buffer to the hardware JPEG encoder, which returns a buffer to the camera app then saved as a file. – during the HDR+ processing in background, you can press the shutter button again to trigger the capture, but only as long as there is enough available memory to store those multiple exposures as uncompressed image buffers in RAM.
As you can see from this list of operations, the two modes function rather different.
– Standard mode doesn't rely on the CPU to do much beside synchronizing the preview between the camera and the display hardware, then saving the final result as a file on disk.
– HDR+ relies extensively on the RAM and CPU to build (hopefully) better images from many captures.
As a result, both the RAM and CPU are bottlenecks limiting the consecutive shooting capability.
Now you may ask: why isn't HDR a problem on other phones?
There are several explanations:
– Google chose a target that's unsuitable for the Nexus 5X consecutive image shooting. It means too many images in buffer given the amount of RAM and computational capability available, too complex processing.
– Google HDR+ implementation is not optimized enough.
– Samsung flagships since the Galaxy S5 process their HDR rendering hardware-accelerated instead of relying on the CPU. Their implementation is efficient: enough to process the preview in HDR at 30 FPS, compressing the dynamic range more and better than Google's HDR+, it doesn't slow down shooting either. Samsung HDR rendering is even available to third party applications in their Camera SDK while Google's HDR+ is entirely proprietary.
How can Google improve the situation?
– Reducing the amount of captures directed to HDR+ dynamically depending on the load to avoid stopping and making the photographer miss shots
– Reverting to 100% hardware accelerated standard shooting when at least two HDR+ images are processing in background instead of preventing the user to shoot. A standard image is better than no image at all. As demonstrated by +Sam Pullen, the current situation generates user frustration.
– Use more hardware acceleration (OpenGL shaders, Renderscript) and less CPU to improve the HDR+ algorithm speed to catch up with the competition, improving the power efficiency and avoid slowing down even more during consecutive shooting due to CPU thermal throttling.
* 9 frames for HDR+ was mentioned in a Google blog post last year, it could have changed on latest camera app.
I gave a hand to +FrAndroid +Manuel C. to explore the audio capabilities of the Chromecast audio.
Google confirmed what we found in measurements earlier: Chromecast audio resamples everything to 48 KHz 16-bit for both the optical and analog output.
– It is a poor default choice for audio since most material is sampled at 44.1 KHz. – The resampler itself is not so great, introducing various distortion artifacts. – The 16-bit output limitation is not welcome, including for 16-bit material since the volume control is software and digital. – And it prevents playing 96 KHz 24-bit material without loss of quality.
Google say they are working on it, however they didn't adjust their marketing material announcing the support of 96 KHz 24-bit resolution which is rather unfortunate.
I have a lot more measurements and data than the graph +FrAndroid republished, would you like to see them?
I've just seen this article from the +Washington Post circulating, and it is worth questioning the real motivations behind it.
Lets start with the author: writes an article attacking +Linus Torvalds as a person and using fear regarding Linux security as a method to gain legitimacy.
But doesn't understand the difference between an OS and a Kernel, or at least has no issue confusing readers.
"Yet even among Linux’s many fans there is growing unease about vulnerabilities in the operating system’s most basic, foundational elements — housed in something called “the kernel"
And here's the type of stuff the security experts say:
"If you don’t treat security like a religious fanatic, you are going to be hurt like you can’t imagine."
Because we all known dogma and fanatism are the best answers – to any problems.. right? Best of all, this is from a security expert associated to the NSA.
No wonder why Linus ends up saying fuck to this kind of crap. Also, maybe he's not as vulnerable as some would like to initiatives to take control of the Linux project for the wrong reasons, using fear as justification. I'm no conspiracy theorist, but curious elements are right here in the article already.
I wouldn't say reviewing headphones with a scientific approach and objective methods is an easy thing to do: It is not. It doesn't mean it's impossible, by any means.
Today's article from +Engadget illustrates how it looks to me most audiophile equipment (or audio equipment altogether) is evaluated. Heck, for ultra expensive audiophile stuff, broken is good enough!
At the point where function itself is optional, you can guess the importance given the the actual product performance…
Quoting: "But the more I think about it, the more it doesn't matter."
This one, starting from 4.1.2 AOSP and binaries required more work, including on:
* RIL, for Radio Interface Layer: the software allowing the modem and CPU to communicate, managing phone calls, text messenger and data transfer
* HAL, for Hardware Abstraction Layer: what allows Android OS to communicate with low-level drivers
* Kernel: support Android M required features
* ART Runtime tuning to adjust for large apps compilation
* Partitioning: using the larger partition as Ext4 /data instead of FAT32 /sdcard, like introduced on HoneyComb tablets and used in all current devices.
* BGRA8888 supported added in Android as it's what the GPU has instead of RGBA8888
I'm gonna try that shortly after copying a backup of the 4.1.2 stock rooted (with Voodoo Sound of course) running on mine at the moment!
Android M on Nexus S – Dmitry Grinberg
How to build Android Marshmallow on Nexus S. The story… Nexus S (crespo) got its last update in Oct 2012. It was Android 4.1.2 Jelly Bean. Android M (marshmallow) just came out recently. I decided to port M to crespo for fun, and as a demo taht old hardware can in fact run new versions of …
While +Ron Amadeo's article is mostly negative, here is a different interpretation of the same elements:
Google integrated its partners feedback as well as the market response with pragmatic and realistic changes benefiting everyone.
Launch
It made sense when launching the Android One program for Google to keep a tight control on specs, software development and distribution.
– Less hardware variety allowing to reduce development costs and delays, improving user experience consistency and reducing the amount of bugs in the beginning.
– Google controlled updates was the best way to enforce their priority to deliver updates, and through this channel gain immediate feedback on how to reshape as needed the Android platform to be best suited for the new markets targeted.
Maturity
– Boarder choice of components and suppliers allows to drive costs down by enabling more competition.
– Distributed software update processing as well as bug handling instead of centralized allows to scale. As we could observe on Android Wear, Google-only management lead to severe bugs staying unfixed for months.
– OEMs becoming more involved encourage them to advertise and sell more Android One devices, now having a chance to develop a relationship with their customers and build their brand long term. This relationship is crucial in market like India. OEMs can now capitalize on brand loyalty obtained through affordable Android Ones devices with good hopes of selling higher margin devices to the same customers next.
– Google keeps contractual guarantees negotiated with OEMs partners in terms of software update distribution which was or still is the main problem to solve. Same results at a lower cost.
Since the Android wear update upgrading Google Play Services to the 8.2.98 version, my unit didn't experience the battery emptying bug I mentioned so often before.
I am hopeful that this issue, which was making the watch essentially a defective product is now fixed, possibly thanks to the involvement of +Wayne Piekarski who gave my many bug reports to the right people. Last month he mentioned that the bug was fixed internally, although without more details or an ETA.
The bug occurrence was random however so it's hard to tell for sure by definition hence my question:
Is it fixed for you too?
The screenshot shows battery statistics with light usage – sitting on my desk aside from a few hours a day when I go for a walk: the watch battery performance is now pretty solid.
Building Android from its gigabytes of source code take a little bit of time. And yes this is an euphemism, as we are talking about roughly 2 hours for a reasonably powerful quad core desktop CPU.
Of course when working with this gigantic project, you learn quickly how to build only what's necessary and its dependencies.
It's only the beginning since there's an effort to rework the build files design and WebView chromium now comes pre-built (which alone divides the full build time by almost two).
