I'm a new user, not allowed to post in development forum. So forgive me for posting here. This is in response to the "[ROM][AOSP][hermes] Delirium Sense7 thread. This ROM produces 80KB in logcat every second, which is the repetition of the same message:
Code:
D/AudioALSACaptureDataProviderNormal( 263): readThread, latency_in_us,0.000119,0.000299,0.001681
D/AudioFlinger_Threads( 263): need 54274 frames in to produce 18091 out given in/out ratio of 3
D/AudioFlinger_Threads( 263): not enough to resample: have 1025 frames in but need 54274 in to produce 18091 out given in/out ratio of 3
D/AudioFlinger_Threads( 263): now need 1024 frames in to produce 341 out given out/in ratio of 0.3333
D/AudioFlinger_Threads( 263): success 2: have 1025 frames in and need 1024 in to produce 341 out given in/out ratio of 3
V/AudioTrackShared( 263): mAvailToClient=0 stepCount=341 minimum=342
D/AudioFlinger_Threads( 263): need 53251 frames in to produce 17750 out given in/out ratio of 3
D/AudioFlinger_Threads( 263): not enough to resample: have 2 frames in but need 53251 in to produce 17750 out given in/out ratio of 3
The messages hint a problem in audio re-sampling, but since the mobile phone produces this messages without any audio sounded, it's either misbehaving or a secret recorder has been running. Anyway, is this an ignorable problem? Perhaps the ROM set debug level too high (I'm new to android dev). I currently filter out these messages in order to work on my other projects.
Eventually I am switching away because of the following bugs.
- usually my SPI client (nonoh) produce noise while dialing
- Google Map freezes, mostly when I am on the move (GPS location change)
- Tethering doesn't work - the other wifi clients connects, gets IP address but can't surf.
Hope the next ROM to try is better.
FWIW, this is due to "Google Now" detection being set to "From any screen". Turn that off, and these will go away (but if it's only when charging and screen on, it might not be that big of a deal).
Related
Still zeroing in on getting this working the way I want (caveat: I am much pickier than most people about sharpness, jitter, pixilation, and the like), but I have managed to get some improvement in playback. Here's what I'm finding so far:
o) Using Pocket Hack Master (which can only be used when my device is plugged in to either the wall charger or the USB sync cable; don't ask me why), I have hard-set the system speed to 520MHz, and have set the speed for TCPMP to "maximum" so that it overclocks when I run it.
o) I converted several test files (I have a set; I'm obsessive) at 500kbps video, 80kbps audio, 40KHz audio frequency.
This gives smooth playback except when there is too much data, i.e. when there's a lot of motion in the image and its a complex image. (Trees with lots of leaves seem to be a good test case.) For example, in the scene in "The Incredibles" where Mr. Incredible is shaking a tree to get a cat out, the image freezes a bit. In the scene in "The 40 Year-old Virgin" where Our Here is biking down a tree-lined street and the camera pans up to the trees, the image freezes a bit. Images like that.
It's unfortunate that I have to ramp the bit rate down so low, although on this screen--as opposed to a QVGA screen--the images are much sharper at lower bit rates. Even so, I still want to see what other people say about, for example, using "true" VGA mode, different versions of TCPMP, and the like. It would be nice to be able to convert in the 700-800kbps range; in my past experience, that gives a good compromise between image sharpness and file size. (I personally don't mind a movie taking up a GB of space; I want that movie to look good, dammit!)
Doug
Please correct title or delete.
V
Hi I really want this app in my ETEN M700 WM6.1
GPSPerformance
can any body hackit? or any one knows a freeware version?
this it what it does:
GPS Performance is a must have application for people with performance cars interested in performance statistics. Using a regular GPS receiver and sophisticated alorythms, GPS Performance is able to accurately measure 1/4 mile dashes and 0..60 timings.
Circuits can be defined for timing laps and up to 5 split times per track can be added. Of course the runs are fully configurable, allowing custom distances and speed ranges to be specified, and tracks are created simply by driving around the circuit.
Each type of run has its own memory, storing the last ten runs (100 runs for lap times). The best time and average time are displayed. Different runs can be plotted and overlayed against each other using an informative graph. G forces for recorded runs can also be plotted and compared.
Use GPS Performance to discover exacly what your car is capable of and boast to your friends. Use it to perform `before and after` runs to test performance modifications such as sports air filters and sports exhausts. It can also be used to detect small changes in performance to give early indications of possible engine problems.
Features:
* Lap Times including split times with 100 lap memory
* Accelerations Times such as 0..60 or 30..70
* Distance Times such as 1/4 mile
* Avergage Run Times
* Best Run Times
* Graph plots for all runs
* MPH or KPH
* Graphically overlay up to 10 runs together for comparison
* G-Force calculation
* Portrait and Landscape supported
* Time and Date stored with each run
Click to expand...
Click to collapse
Thanks in advance
Are you asking the community to hack a commercial/trial product? If so, please be aware that this forum doesn't support warez/cracking, and will not help you.
I'm looking for a true indication of FPS for my device. Standalone benchmark apps are nice, but only report marks gained from within their own processes, which in most cases there is little overhead and are written to be as streamlined as possible.
Does anyone know of a benchmark or any other type of app, that continuously displays a frames per second value in the top notification bar while you're running everyday apps?
I'm in a discussion with an iPhone user who mentions that regardless of the running app, the screen runs at a constant 60fps, but I find this to be a bit of a stretch.
I'd be curious to know what the average running FPS is while just normally using this Android device.
A FPS monitor isn't going to tell you much when most applications really don't update the screen more than once or twice in a second. Sure, it'd tell you if the phone's refreshing properly when you're scrolling, switching screens, etc, but the metric is pretty much useless outside of games or the standalone benchmarks you mention.
You can certainly get a 'constant 60fps' if the display update layer and the application layer are disconnected from eachother - basically if an app can only draw 10 frames per second, you'll still only see 10 changes per second, all the while the phone can happily tell you that it's updating the screen at 60fps. This is more akin to refresh rate than frame rate.
A better metric would be a process that takes low-priority and updates a counter at some set interval. If it falls behind, you know things are running slowly (ie. it can't get a CPU slot to update).
So yeah, the FPS indicator you're looking for wouldn't do much but tell you your refresh rate, which really doesn't change.
Ahh, good points. I hadn't thought it through that way.
To pass the time I created this application, he may not have any good but it works!
The process is simple, I created a view that contains a number of layouts specifically*made.
The result is to obtain a scrollable vertical layout long at will and the purpose is to create the longest supportable by the device.
I have a preset standard lengths and the longest is the distance earth-moon (384400000m - 238 855.086 mi) but you can also set no limit until the crash and the maximum length was 7,708,463 km (4,789,816.84 mi )
I have not implemented the function to recreate the layout until just before the crash (to get a scrollable layout) but it's a simple thing to do, I can do it in a couple of minutes and upload the new application if someone is interested
I tested the function without limit only with the emulator because it took several hours but I would not stress too much the phone.
What do you think? I did an interesting thing, or is a WTF in itself?
If you want to give it a look this is the link
https://play.google.com/store/apps/details?id=free.tothemoon.rmk
Almost chrashed my phone
HAAAAAAX!!!
After some poking and prodding at my A7+, I was surprised by some of it's short comings. A couple in particular are easily rectified. The following changes require root access and some means of editing your /system/build.prop file (Root Explorer is real nice).
The first problem was that the screen was not as sharp and crisp as I would have expected for a 7 inch tablet running at 1024x600. As someone on these forums pointed out the LCD density is set incorrectly for the display, and that causes some problems with position/size of things in various apps. To fix this you need to change a line in /system/build.prop.
Code:
Default: ro.sf.lcd_density=200
Correct: ro.sf.lcd_density=160
The next problem is that the device reports OpenGL ES 1.1 when queried through the Android APIs, but when queried through the OpenGL APIs it reports OpenGL ES 2.0. This is a kinda big problem if you like playing indie games because few programmers will bother with low level calls when there is a decent framework to take care of that for them (let's them focus on their product instead of the boilerplate under it). To change this so that it reports correctly in the Android APIs you must add the following to the bottom of /system/build.prop.
Code:
ro.opengles.version=131072
The last problem I've not found an elegant solution for. The tablet doesn't seem to want to engage the second processing core unless a program explicitly demands it. The workaround for this is to install System Tuner, go to CPU, and slide the second CPU (left slider) all the way up, it will not keep this setting upon reset, it does keep it through sleep though. It is much more battery intensive with the CPU full engaged like that, so you'll want to kick it back down when you don't need it. One example where this made a huge difference: I was trying to watch a video encoded in x264 hi10p, without the second CPU engaged the video played slowly while the audio played full speed, with the second CPU engaged it played full speed without so much as a stutter.
I'm going to dig into the tablet a bit more now that I have a terminal emulator and ssh server set up on it. If there are power profiles like the stuff I've had to tweak on my laptop, can likely squeeze out a lot more performance with some fine tuning.
eideticex said:
After some poking and prodding at my A7+, I was surprised by some of it's short comings. A couple in particular are easily rectified. The following changes require root access and some means of editing your /system/build.prop file (Root Explorer is real nice).
The first problem was that the screen was not as sharp and crisp as I would have expected for a 7 inch tablet running at 1024x600. As someone on these forums pointed out the LCD density is set incorrectly for the display, and that causes some problems with position/size of things in various apps. To fix this you need to change a line in /system/build.prop.
Code:
Default: ro.sf.lcd_density=200
Correct: ro.sf.lcd_density=160
The next problem is that the device reports OpenGL ES 1.1 when queried through the Android APIs, but when queried through the OpenGL APIs it reports OpenGL ES 2.0. This is a kinda big problem if you like playing indie games because few programmers will bother with low level calls when there is a decent framework to take care of that for them (let's them focus on their product instead of the boilerplate under it). To change this so that it reports correctly in the Android APIs you must add the following to the bottom of /system/build.prop.
Code:
ro.opengles.version=131072
Click to expand...
Click to collapse
Wow. The lcd change is really nice- everything is much smaller but fits and looks sharper and cleaner. I saw that same post awhile ago but didn't pay much attention to it. Videos also look better.
I'm going to dig into the tablet a bit more now that I have a terminal emulator and ssh server set up on it. If there are power profiles like the stuff I've had to tweak on my laptop, can likely squeeze out a lot more performance with some fine tuning.
Click to expand...
Click to collapse
I really hope you continue to work on this tablet- it definatly needs some work. You should talk to Jam4 over at TR about this. He is making a HC ROM, and I bet he could bake the CPU changes right into the ROM.
I'm new to this stuff but where does the density come from? when I did my own math it seemed closer to 170.
Naidosh said:
I'm new to this stuff but where does the density come from? when I did my own math it seemed closer to 170.
Click to expand...
Click to collapse
Sorry been busy with my coding projects, so haven't popped into the forums in awhile. If I'm right in assuming you calculated that based on the visible screen space and resolution, you have to consider that screens have a metal trim around the edge which covers a few pixels of width and height on each border. If you dig through the source code that eLocity released, there are padding values in place to compensate for those when rendering to the screen. Almost every display out there does this, LCDs are pretty good about minimal over size, but old CRTs would have as much as 20% of the screen tucked behind the bezel for a nice border.