Related
These are the specs of our Gyro/Accelerometer for anyone that might be interested:
http://invensense.com/mems/gyro/mpu3050.html
Smallest and thinnest 4x4x0.9mm QFN package for portable devices
6-axis MotionProcessing™ capability using secondary I²C interface to link an external accelerometer
Digital Motion Processing (DMP) engine supports 3D motion processing and gesture recognition algorithms
Programmable digital high-pass and low-pass filters support for each motion processing application
MotionApps™ Platform support for Android™, Linux™, Windows™, and Windows Mobile™ platforms.
Digital-output X-, Y-, and Z-Axis angular rate sensors (gyros) on one integrated circuit with a full-scale range of ±250 to ±2000°/sec
FIFO buffers complete data set, reducing timing requirements and interrupts on the applications processor
Programmable interrupt support features including gesture recognition, panning, zooming, scrolling, zero-motion detection, tap detection, and shake detection
10,000 g shock tolerant
Low 6.1mA operating current consumption
Three integrated 16-bit ADCs provide simultaneous sampling of gyros
Digital-output temperature sensor
Click to expand...
Click to collapse
Thanks,didn't know Accelerometer have many features.
Robert235 said:
Thanks,didn't know Accelerometer have many features.
Click to expand...
Click to collapse
Yeah I was kind of blown away.
Welcome to the Perseus kernel! I thought it would be a nice catchname considering the Galaxy/Universe/Pegasus themes.
This is a direct port of my kernel on the Galaxy S3. I am using the same source base for both devices for the kernel, just with a different configuration file. The kernel images are not interoperable! I will continue development in parallel for both devices, with the Note 2 having maybe some delay due to third party testing.
I'm trying to be more cutting-edge in terms of development in this kernel. In contrast to other kernels and philosophies of other developers, I don't believe giving the users more choice is a very smart thing to do. As such you won't find a dozen different governors or twenty different settings for this kernel. There is a optimal, or at least, most optimal setting on which the devices operate both in terms of performance and power management. For the average user this kernel will brings lots of benefits to battery life, screen improvement, fluidity and sound enhancements without having to set up any of the configurations.
The kernel comes with a configuration application called STweaks, and is installed automatically with the kernel. You will find all advanced options in there.
Don't be scared by the alpha denomination of the kernel, I'm just taking the traditional naming scheme where alpha designates feature development, beta is feature-completeness, and final will actually be when I'll actively stop developing the kernel. The kernel is very stable, and any bugs are fixed in hotfix versions (alpha x.y)
The kernel is also being maintained and released cross-device for the I9305 (S3 LTE), i9300 (S3) and N7105 (Note 2 LTE) and shares the same base-source. I solely own a I9300 Galaxy S3, but since all the phones derive from the same Midas platform, I merely adapt the differences without having the other devices.
Features / changelist:
Perseus alpha36.3 (26/04):
Fixed slice lookup issue on ABB: It's recommended you put your slices back to default before flashing if you changed them to borderline stability values. Please upgrade.
Perseus alpha36 (22/04):
Adaptive Body Bias control (ABB). (Experimental feature)
Body biasing is taking advantage of transistor body effect for binning the chip depending on its quality. In fact, this is used on the latest Samsung SoCs both for reducing power consumption and validating bad chips by adjusting their electrical characteristics.
The body bias is dictated by the voltage applied to the transistor gate (The usual voltages you're all used to) minus the voltage applied to the transistor body. The resulting bias can change the transistor's electrical characteristics in two possible ways:
Before reading on: A transistor's voltage and operating frequency is defined/limited mostly on its threshold voltage. Wikipedia has a neat visual representation of this; voltage must raise to a certain point for the transistor to be able to switch and operate. This threshold voltage can be highly dependant on temperature, influenced by the body effect, and defined by the manufacturing process. What we're doing nowdays with undervolting is to get as near as possible to the upper bound of this threshold voltage.
With that in mind:
Forward Body Bias
A FBB is defined when the bias of the gate voltage minus body voltage is positive, meaning the gate voltage is higher than the body voltage. This has the effect of reducing the threshold voltage. By reducing it, you can achieve lower voltages, or be able to clock the transistor higher. However the side-effect of lowering the threshold voltage is that you are sacrificing power leakage, meaning that the lower the threshold voltage becomes, the higher leakage current in the transistor becomes. This leakage power rises exponentially with a linear lowering of the threshold voltage. This is what is called static transistor leakage.
Reverse Body Bias
A RBB is defined when the bias of gate voltage minus body voltage is negative, meaning the gate voltage is lower than the body voltage. it has the direct opposite effect of FBB, it raises the threshold voltage thus you would need a higher gate voltage for switching, but however you also dramatically decrease static leakage.
What happens is that you want to use RBB when idling, and a reduced RBB, or even FBB at very high clocks.
Samsung currently uses this on top of voltage scaling to bin their chips. Here's an excerpt of the stock body biasing on the 4412 Prime chip (I'm using that one as an example as it has better adjusted ABB values over the Rev 1.1 chips).
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
To find out your ASV group: You can read out your ASV group in /sys/devices/system/abb/abb_info now.
I have rewritten the ABB scaling logic/driver for CPU, GPU, MIF and INT voltages.
In the current implementation, since it would be insane to have paired-up gate-body voltages divides the frequency range in several slices; even Samsung uses only three voltage ranges on the DVFS scale. I divided the frequency ranges as follows:
CPU: Divided into four slices, with frequency ranges of 200], 800], 1600] and ]1600 Mhz.
GPU: Three slices: 160], 533] and ]533 Mhz.
MIF and INT: Both only two slices with the bottom frequencies for each as middle-threshold.
As mentioned above, controls can be found in /sys/devices/system/abb/ and the entries are self-explanatory. You can also change the frequency slice limits per sysfs, however in STweaks I only included the voltages for each slice only for now.
Disclaimer
{ And that's about it in that regard. I have tried testing things over last couple of weeks, but I haven't come to a solid conclusion yet beyond what's presented by the stock characteristics: It's up to you people to do some advanced testing on the matter. My limited empirical testing in terms of voltages tells me it works as intended, but if a user with advanced measuring equipment would do similar testing to what I did back on the 4210 it would be perfect. }
zRAM: Switched over from LZO to Snappy compression algorithm, this provides much faster compression and decompression than the LZO implementation which was in the current kernel. I updated the Snappy libraries to the latest original CSNAPPY implementation, so this is extremely new.
Some kernel internal updates to speed up hotplugging and improve I/O latencies.
A correctly (Unlike basically every other kernel out there till now) applied load averaging patch regarding fixing a Moiré pattern in the scheduler load calculations which was floating around.
Fixed mono and equalizer switches in the sound engine. (Thanks to sorgelig for beating me to it)
Fixed led controls to behave correctly with user-space apps.
mDNIe digital brightness reduction:
You can now lower the brightness to basically nothing via this: it uses the mDNIe engine to digitally remove luminance from the RGB channel values, as opposed to reducing brightness via a proper backlight/display driver. The side effect of this is that you lose colour resolution somewhat, but is a practical and working method to reduce the too bright minimum values of our displays.
You have three configurables:
A reduction rate which you want to apply, this is the intensity of the darkening you want to achieve.
The take-over point; the backlight driver gets fed brightness values from 0-255 (In reality values below 20 have no effect). The take-over point is the point where the digital brightness reduction starts, on a reverse scale. The reduction is applied linearly from 0, (Full reduction taking place), to the take-over point (Zero reduction). The stock slider doesn't go below 20 in the interface, so practically the full reduction rate is never applied unless you use a third-party brightness controller app, just to keep that in mind, but in practice it doesn't matter.
Auto-brightness input-delta: This is needed because the stock framework is retarded in the values it forwards to the kernel, you can adjust this to avoid having brightness reduction when you don't want it on auto-brightness.
Somebody needs to edit config_autoBrightnessLevels, config_autoBrightnessLcdBacklightValues in framework-res.apk\res\values\arrays.xml to fix this.
Optionally, if you use a third-party app like Custom Auto Brightness which allows backlight values of down to 0, you can avoid this problem.
The register hook needs to be enabled to be able to use this function.
EA8061 Note 2 owners only: increased the maximum brightness by 50 candela: the manual controls were limited to 250cd as maximum as opposed to 300cd which was only usable during auto-brightness, and unusable for any third-party apps. This doesn't apply to users with S6EVER02 controllers.
Unaligned memory access throughout the kernel when applicable.
Switched over to GCC 4.7.3 Linaro toolchain for compiling.
Perseus alpha35 (06/04):
Further rewrote the in-kernel audio controls:
Threw out the old detection methods for something more robust.
This particularly enables non-cellular applications such as Skype, Viber, and so on to be detected correctly. A "calling" state now includes any and all use-cases where the audio is outputted via the phone's earpiece. This fixes microphone levels for such apps to correctly use the calling sensitivity value.
Added microphone level for camera use, this state is enabled whenever a camera stream is active. It should give more options into adjusting things to your likings.
By now the sound engine has only little similarities to Boeffla, any bugs and feedback now go directly to me.
Developers only: MHS: Added a new small tool for tracking media use and reporting it to other in-kernel drivers. Capable of detecting video recording, decoding and camera streams for now. See commit for more info.
mDNIe control changes:
Removed several controls in STweaks simply because people misunderstood them or misused them, or they simply had no rational use.
Video detection, now with the help of MHS, is no longer limited to the stock video player. Any video players using hardware decoding will now be able to make use of edge enhancement, HDR and DNR, this includes any web-based players and the YouTube app.
Custom LED controls implemented; Exposed most variable controls for the notification LED via sysfs and STweaks (LED tab). :
Control LED brightness. Currently the OS dictates, depending on brightness detected by the light-sensor, wether to run the LED in a low-power mode or in a high-power mode, you can now set brightness for both.
Blinking control, this is basically the shape of the wave-pattern that the LED blinks in, you have several controls, best described the data-sheet description:
The fade-in time period is TT1 in the graph, while the fade-out period is TT2.
Slope (1/2/3/4) detention time represents DT1,2,3,4 in the graph, it controls how "steep" the four different curves are.
The LED fading checkbox simply switches between having the detention times controlled by the sliders to having them to 0 (Stock blinking behaviour).
The ZRam control is found in the I/O Tab in STweaks. Set it to 0 to turn it off completely, any other value to turn swap on. Changing value takes about ~10-20 seconds depending how loaded the disk is with swap pages so don't piss your pants if it doesn't react immediately.
Sources:
https://github.com/AndreiLux/Perseus-S3
Credit and thanks:
gokhanmoral, netarchy, and anybody credited in the commits.
Thanks to sswagonman for the initial testing.
TL;DR: before flashing aside from known issues in the second post.
This isn't an AOSP kernel.
Please choose the right version between N7100 (International 3G) and N7105 (International LTE).
The kernels are labelled for their respective target device. You have no excuse in messing this up.
Other variants
Note 2 L900 (Sprint) Download
Note 2 i605 (Verizon) Download
Note 2 T889 (T-Mobile) Download
Note 2 i317 (AT&T) Download
U.S. Cellular R950 & China Mobile N7108 (这个版本是专为中国移动用户提供的Samsung Galaxy Note II 变体,中国移动版-N7108)
Kernels for these variations of the devices below.
Known issues [Updated 10/01]
None.
Older changelogs
Perseus alpha34 (22/03):
Updated sound engine. Based on Boeffla (Andip71)sound but custom fork with rewritten system interface and some other code re-factorings.
Should fix all FM Radio issues.
Brings us saturation prevention for the equalizer.
Privacy mode.
Microphone level control
You now have control over the speaker equalizer via sysfs, please visit /sys/class/misc/wolfson-control/ the controls are self-explanatory.
I removed the equalizer pre-sets from STweaks, if you want, set them manually:
Bass-extreme: 12 8 3 -1 1
Bass and Treble: 10 7 0 2 5
Treble: -5 1 0 4 3
Classic: 0 0 0 -3 -5
Pleasant for ears: 4 3 2 3 1
Eargasm: 12 8 4 2 3
I recommend HeadphoneAmpControl (thread - Play Store) for controlling the volume directly on a hardware level; it will overwrite the digital volume of the OS and use the hardware amplifiers only.
Enabled ZRam by default with disk size of 200mB and swappiness of 90%.
Applied a requested patch which allows PCs to be booted off from the phone storage.
Perseus alpha33 (26/02):
Revamped and hopefully final version of mDNIe controls:
The controls work now on two levels: First we have a master sequence that overrides any and all of Samsung's settings; The master sequence is calibrated to sRGB norms on a precision level equalling and even surpassing the iPad3/4 with help of professional equipment (Spectrophotometer) and professional hands. All credit goes to Slimer777 for his incredible job in doing this.
Calibration data:
Simple report: Download
Detailed calibration report: Download
Advanced colour management report: Download
(Please note that the "before" values represent the raw screen output without use of mDNIe, these values don't represent any of the live profiles)
The master sequence works as as the calibrated base; for people not wanting to bother further with any more controls, you simply enable this and you're done. Please keep in mind that every screen is slightly different and variations in manufacturing affect image output; this works as a base calibrated as close as possible to sRGB / Rec. 709 specifications.
Second part is the register hook, it catches effect values and modifies them by applying delta values available as controls in STweaks and in /sys/class/misc/mdnie/hook_control/.
Leaving both these options will give you Samsung's default values, plus the black crush fix.
The register hook, while used on Samsung's profiles, is not capable to alter effects which are not integrated in that screen profile's value sequence, the "Movie" profile for example lacks some effects present in the "Dynamic" profile. The same is valid when having different scenarios, the "Camera" scenario will use different effects in its base than the "UI" scenario. To fully explore all possible effects, use the Master profile as it integrates all effect values known.
Each control has a master kill-switch which enables or disables the effect. This varies by profile and scenario, so you have control to only "toggle" the switch, whatever its state may be in.
Digital noise reduction - Reduces and flattens out grain. Advanced controls are found in the hook_control folder with the dnr_ prefix.
High dynamic range - A HDR effect which brings out details in dark and extremely bright scenes.
Digital edge enhancement - An edge enhancement effect. What we previously called "sharpening". Divided in controls for radius, amount and threshold. Read the Wikipedia page for more information. More advanced controls found in the sysfs under the de_ prefix.
For the above three effects, scenario consideration is taken into account. You can enable/disable them depending when you want it to be applied. Please be aware only the stock applications trigger the scenarios. I will try to enable at least the video scenario depending on when the hardware decoder is active in the future so that they are enabled also in third-party video players.
Chroma saturation control - Same as in previous version but with fixed labels.
Colour temperature control - By default this is disabled on all profiles, however, if your screen has a tint to it, this is the first control you should try to fix as it alters temperature on all channels.
The SCR controls are colour channel filters working on the Red, Green, Blue, Yellow, Cyan, Magenta, White, and Black channels.
Imagine the controls as manipulating the corners of the RGB cube:
(Credit to Wikipedia for the graphic)
By controlling the RGB coordinates of each corner/channel we can mould the cube into a different shape. At the same time the cube is projected onto a hexagon; the perimeter / angle of the hexagon represents the colour hue, the radius of the hexagon from the middle represents chroma. We can use the chroma saturation controls to "push in" each corner of the cube, while moulding the corner's directions with the RGB controls. The RGB coordinates can be transformed into the HSL space space if needed, however I didn't include this function yet as I don't feel the need for it.
STweaks has controls for the RGBYCMW channels, the K (Black) channel I left out because it makes no sense in altering it, but can be found in the sysfs folder.
Several controls have a "factory setting" switch, this are the burned in-hardware values for some controls, they overwrite the controls themselves.
Additionally to the controls exposed to STweaks, there are several other effects and modifiers exposed in the sysfs interfaces. This also includes the gamma curve controls for levels 0-255 in steps of 16.
There are also some additional unidentified configurables which I wasn't able to properly give a name to or had no effects: Dithering, ABC (Seems to give a gamma brightness boost), SCC, UC, and MCM (Colour temperature) configurables whose exact effect isn't documented.
Perseus alpha32 (29/01):
Charging control implemented. This is my own version.
Charging currents:
Charging currents are dictated by input and charging current limits. The input current is the current flowing into the device through the USB port at 5V. The charging current is the current delivered to the battery at usually 4.35V. The device can have a higher charging current than input current because of the voltage differential, usually a 15% discrepancy. You can also have much higher input currents than charging currents, this can be useful when you are using the device in situations like gaming and charging your battery at the same time, provided your charger actually can provide the power.
There are 3 USB charger type categories: DCP / Dedicated Charging Ports which also includes AC chargers, but also special USB plugs; SDP / Standard Downstream Ports which usually includes almost all data enabled USB ports, and CDP / Charging Downstream Ports which includes also data enabled USB ports but which are designed to provide more power, usually on newer laptops where the USB port has a lightning logo next to it. More info here. - Technical explanation here.
Charging logic:
Stable margin removal option. The charger chip is capable of detecting unstable charging sources; it dynamically reduces the input current in 100mA steps until it detects a stable voltage input [We don't have the charger chip datasheet, so the technical explanation is a bit blurry here on how it decides that it's unstable]. It further reduces it by 100mA as a safety margin, you can disable this now.
Complete disabling of unstable power detection. This simply ignores unstable power sources and leaves the input current limit at its set up value. This will fix charging problems people have been reporting. However, please use it at your own risk, the S3 chargers which have had these symptoms clearly have some issue in their hardware so you might actually kill them with this option enabled as there is no protection from the phone's side anymore.
The actual input current limit can be read out in /sys/devices/platform/samsung-battery/power_supply/battery/current_max, so you can see the real limit there, it's the closest thing we have to the actual charging current on stock values since there is no hardware to read out the live currents.
Voltage control:
Hard voltage control: 4.20, 4.35V, and 4.40V charging voltages are available. This is included for anybody running on third-party batteries, whom most of them have a 3.7V battery chemistry as opposed to the 3.8V on the stock battery. These batteries should be charged at 4.2V instead of 4.35V.
Soft voltage control: As opposed to the hard voltage control which is the voltage which the charger chip provides to the battery while charging, the soft-voltage is the battery voltage itself. 3.7V batteries have a top-off voltage of 4.2V and 3.8V again 4.35V. The default limit on the stock battery is 4.30V before the charger logic stops and considers the battery as full. This is also merely provided for 3rd party batteries which should be charged at lower voltages. If you overcharge your battery beyond these what are safe considered voltages, such as raising the default 4.30 top-off voltage to the design 4.35V or even higher, you are running into the risk of damaging the battery or even causing it to melt-down. Use at your own discretion.
mDNIe sharpness and RGB/YCM chroma saturation control in STweaks:
I started implementing sharpness control in STweaks and went a bit over-board instead of a simple checkbox; You now have controls over the mDNIe registers as a delta offset value compared to the stock register values. I'm applying the offset to all mDNIe profiles and scenarios which have the specific post-processing effect active in that specific scenario. Meaning, that you start with the default profile; Dynamic / Standard / Natural / Movie and have the delta offset applied on top of that.
Sharpness delta. This is what brought most of the quality difference in hardcore's original tweaks. You can now fine-tune it to your own taste, and also take into regard that it produces a different effect for each screen profile while having the same delta - the base values between the profiles are different.
DE control - I don't know what this actually does and I couldn't discern much difference between the values, but it used to be disabled in hardcore's tweaks.
Chroma saturation control: This is composed of 2 values for each RGB/YCM channel. See the Munsell color system for a visual representation of the values controlled here. The chroma curve control describes the curve weight based on chroma intensity, the chroma gain is the chromatic gain that is being applied on the respective channel. Chromatic saturation weight is again another multiplier for all channels combined. I have not managed to properly identify the chroma grey threshold and its effects.
Basically this is like an RGB control on steroids, and enables you to tune your screen to your own liking and calibrate it as you wish. Please note that not all scenarios in the profiles have chroma saturation effects, the Movie profile for example has no effect applied to the UI so chromatic control has no effect on it.
I also want to state that the above are my deductions and theories on the descriptions of these controls, I'm not familiar enough on colour theory to be able to confidently say that these descriptions are correct, and the controls are a work-in-progress for now. Experts are welcome to contribute here.
Front buffer early suspend delay option for those who have issues with the CRT animation.
Did some refactoring on the Mali drivers and fixed a bug which may have caused less capable undervolting than the stock implementation.
Perseus alpha31 (09/01):
Removed my own security fixes and replaced them with the official Samsung one. I guess it can now be disclosed: exynos-mem was only one of multiple entry-points for the memory exploit. We discovered the s5p-smem exploit ourselves back in December but kept it quiet, I fixed that one back in version 29.2 without mentioning. Nobody was secure from a smart exploiter up until then, SuperCurios or Chainfire's software fixes are also just patching a single hole in what is a Swiss cheese. Kernels >v31 and beyond stock LLA are now the only truly protected ones.
Samsung's fix for the sudden death syndrome (SDS) included. It is caused by eMMC failure on phones with VTU00M 16GB internal memory chips with revision 0xF1. You can check your phone with the "eMMC Brickbug Check" in the Play Store (Ignore the message if it says you're not affected, the type and revision is what matters). The patch is a firmware soft-patch that is applied on every boot and MMC resume, it is not a permanent fix. You will need to stay forever on kernels which include the patch, this also includes updated recoveries and their embedded kernels.
Some other minor MMC changes extracted from Update 7 sources.
Perseus alpha30 (06/01):
Internal and memory voltage control. This is the first and only working implementation out there. Memory interface voltage is exactly what it the name implies, the voltage on the chip-to-chip interface from the SoC to the memory chip. Internal voltage is the whole SoC voltage excluding CPU, GPU, and the MIF. This includes all auxiliary function blocks such as the ISP/Image signal processor, camera interfaces, I/O interfaces, display controller and the MFC/Multi function codec hardware video de-/en-coder.
- Internal voltage respectively memory voltage table is found in /sys/devices/cpu/busfreq/ as int_volt_table or mif_volt_table
- The frequencies are defined as OPP's (Operating performance points), internal frequency and memory frequency (And voltages) together as a pair form an OPP. If you want to change the voltages through the sysfs files, keep in mind how you change them. MIF voltages are stored independently with each OPP step. INT voltages are stored in respect of their frequency key.
- Default OPP steps are: 440220, 293220, 293176, 176176, 147147, 110110. The first three numbers represent the memory frequency, the other three the internal base frequency. For example 293220 means the memory interface is at 293MHz (586MHz DDR) and the internal frequency is 220MHz.
- The voltages in STweaks are sorted out through some magic and are frequency unique, I recommend using that for controlling them.
Busfreq logic control added into STweaks, this includes all the already available configurables in the stock kernel with added explanations and I supplemented it with a sampling rate parameter.
Sensorhub driver and firmware updated.
Touchscreen driver and firmware updated.
Replaced pegasusq's runqueue detection logic with a new more superiror and precise in-scheduler collection logic, I found that the real runqueues are much less than what was previously reported. This should help a lot with hotplugging.
Enabled AFTR by default since we are now running very often in single-core mode. Keep in mind this mode is WFI Idle + LPA + AFTR.
Fixed a kernel bug which was eating up randomness entropy. This is related to that whole seeder business - please don't use any of those fixes. I also disabled virtual addresss randomization and at the same time disabled entropy generation from the block layer, which should avoid I/O overheads.
I raised the LPA CPU idle target residency, and fixed a bug in the ABB control for voltages for 900 and 1000MHz. I suspect these two to be causes of the sudden reboots for Note 2 users, and may fix them.
Perseus alpha29 (18/12):
I'm doing a quick release because of the security fix, not very feature rich.
Fixes the exynos-mem security hole. This is my own fix and will not break camera. Read about it here. You don't need to use Chainfire's or Supercurio's fixes, in fact, you shouldn't use them because of the camera.
[*]Updated Wifi drivers.
Increased max brightness by 50 candela. (Thanks nebkat)
Added GPU utilization control to sysfs and STweaks.
Changed default GPU thresholds to more relaxed values (75/17)
Added block device read-ahead control to STweaks. Additionally set the default read-ahead for internal memory to 256kB and 1mB for SD cards.
29.1: - Reverted the Wifi drivers back.
Perseus alpha28 (13/12):
28.1: I reverted the striked out changes due to exFat. I changed my mind due to demand. I apologize for the chaos.
On your SD card showing up as damaged: it is not.
I made a decision in terms of exFat compatibility; either I advance the kernel with newer upstream Linux versions or stay back and keep compatibility with the exFat modules. While I have nothing against proprietary modules or such, not being able to adapt them to the kernel is not optimal. You can format your cards to FAT32 or ext4 without much issue. Please back up your data and format your card accordingly before flashing v28.
[*]Updated the block system to Linux kernel 3.3.
Introduced FIOPSv2, ROWv4, ZEN, BFQv5 as new I/O schedulers;
FIOPS is the new default scheduler, it's a CFQ like fairness scheduler optimized for solid state storage. ROW should be the actual better performer here as it has superior logic, but I didn't set it as default because of some lags when installing applications. ZEN is just a mix of SIO and Deadline and nothing special. BFQ seems to underperform. I recommend the first two over everything else, and added the latter two just for comparison's sake.
Added dynamic Fsync control (Faux123). It disables Fsync only when the screen is on. Enabled by default (Fsync off).
Changed some logic on when the adaptive scaling voltages are applied in the kernel init sequence. This fixes GPU voltages not being applied at boot and also fixes the wrong default voltages being displayed in STweaks.
STweaks tab for I/O with scheduler selection for each device block and also dynamic Fsync.
New script side feature in the uci.sh framework: When inserting an override.profile file into the profile folder (/data/.perseus), the entries in the override profile will supersede the ones in your default profile. You can use to make CWM zips to turn off set at boot flags or to share targeted settings with others. The override is applied once at boot after which the profile deletes itself.
Perseus alpha27 (02/12):
Sources updated with various updates from N8000u1 base. Included are following important changes;
Wacom drivers, Sensorhub firmwares, touchscreen updated.
Updated wireless drivers.
Adds a delay to SD Card host controller power-down, which I assume is to prevent some corruption. There is a specific change to Toshiba 19nm manufactured SD Cards, these are mostly the latest SanDisk 64GB cards. Together this may fix issues users have had.
Updates the camera interface, Video4Linux and Jpeg2x drivers and this fixes compatibility with 4.1.2 ROMs. Backwards compatibility is retained.
Other updates which are more transparent to the end-user.
Removed the sharpness modifications due to demand.
LTE devices only: Disabled CPU frequency clock while connected to a cable.
New PegasusQ logic:
- We now have additional conditionals on the hotplug logic which checks the total load across all cores and is able to bias towards a specified core count if the load is low. This is useful because previously we could have had frequency spikes and lots of low-load threads triggering a hotplug-up while in reality it wasn't needed. The core count is more biased on keeping 2 cores online in most cases now unless really needed.
- The way freq_step is handled has changed. We now take the remainder of load space above the up threshold and dissect it into three slices each having different frequency increase step sizes. The first two slices are each of up threshold differential size, lop-sided towards the lower end of the load scale. We specify the slice size and freq_step delta in regard to the original freq_step.
- A new fast-down scaling logic; if frequency is beyond a certain threshold, we take a heightened up_threshold value solely on the down scaling logic to scale down more aggressively from the higher frequencies.
Audio enhancements (Gokhan Moral's port of Voodoo sound) re-enabled. Call-detection is currently broken (Effects are applied during call while they shouldn't be), but this fixes the effects not being applied otherwise. (Thanks to sjkoon for finally debugging that)
STweaks. This is my custom implementation of the kernel side, based on Gokhan Moral's initial implementation.
- CPU overclocking and voltages interface.
- Configurables for all CPU governor settings.
- GPU overclocking and voltage interface.
- Interface for audio enhancements.
Just an explanation in regard how uci.sh (Script framework on which STweaks is built) works: The settings displayed in STweaks are the defaults with which the kernel boots the first time and are saved as a profile. The saved profile settings are applied before anything else on boot, including init.d. The values displayed in STweaks do not correspond to live kernel values, but the values saved in the profile. As such if there is another app or script setting something after STweaks, it will not represent those changes. Please be aware of that. I included labels with the default values for almost all values, they are dynamically generated.
*Note: Currently the labeled default GPU voltages do not correspond the real default ones as the ASV voltages get applied after I'm reading them out for the interface on early boot. I'll fix this later on.
Perseus alpha26 (14/11):
Updated MTP drivers back to the newest version. Fixes some inconsistencies which some people had.
Further increased MMC command timeout from Linux default 300ms to 3s in trying to finally squash errors and "unexpectedly removed SD card" after resume.
Ported Gokhan Moral's mDNIe interface and also added colour tone modes on top of the scenarios. System interfaces are found in /sys/class/misc/mdnie . Input syntax is the same as the output syntax, or, single register-value pairs as a single line in the output format, except 0xFF which is a terminator value.
Increased default sampling rate down to 30ms from 50ms for a bit more fluidity.
Updated Sensorhub drivers from latest sources.
Updated Wacom and E-pen drivers from latest sources.
LTE devices only: Updated some power management functions on the MDM modem from latest sources; this will drastically decrease the amount of wakelocks on mobile data and improve battery life.
26.1
Disabled net_os_rxfilter_add_remove userspace/ROM filter management in the Wifi driver to prevent the operating system of enabling unwanted pass-through multicast and broadcast filters while in standby.
Perseus alpha25 (23/10):
Raised and fixed USB, MISC charging rate to 900mA.
Enabled OTG car dock, smart dock and music dock charging. Alternatively this can be triggered if you short pins 4 and 5 of the USB connector with a 40.2kΩ, 64.9kΩ or 619kΩ resistor.
MTP fixed on OSX devices.
Fixed ROM power savings feature, this was originally broken because of the addition of overclocking, and the same interface that Samsung uses for limiting CPU speed in power savings mode also limits the max frequency to factory defaults. This is now fixed and powersavings mode will throttle to 1000MHz.
Fixed mis-configuration of the default audio settings to improve sound quality, sorry about that.
Ripped out the old GPU scaling mechanisms and scaling logic and replaced it by something new.
The old mechanism was getting overly complicated and was a remnant of the Galaxy S2 where we merely had 2 frequency steps originally; this was fine then, but isn't anymore today. The threshold fuçkery was confusing to a lot of people and people generally misconfigured their settings with inane values.
The new scaling logic follows a more CPU governor-like approach: Scaling up logic is basically the same as before: the GPU will scale up to the next frequency step when the load reaches a certain threshold. Up-scaling takes place step by step. The up-scaling threshold is now global and a single value applies for all frequency steps.
Scaling down in the new logic resembles more like the ondemand method; The scaling down takes place when the load goes under a certain threshold. This threshold is dictated by the up-threshold minus a down-differential. By default they are 90 and 10. Triggering this condition we scale down into a dynamic frequency target capable of accommodating and dictated by the load level. In plain words, we can scale from max frequency immediately down to the lowest one. This will improve power consumption.
Ripped out the old GPU control interfaces and rewrote it with something new to accommodate the new logic. Your old scripts won't work anymore.
We now have 10 frequency steps to the user's disposition; defaults are: 54 108 160 266 350 440 533 640 733 800.
NOTE 2 USERS HAVE 533 AS MAX FREQ.
The new system interface targets can be found in /sys/devices/system/gpu/ .
- freq_table outputs a list of the current frequency table. You can use this interface for configuring the frequencies themselves in two ways:
Pair-wise target setting: echo 533 500 > /sys/devices/system/gpu/freq_table will change the 533 step frequency to 500.
Whole-table echo: echo 54 108 160 266 350 440 500 640 733 800 > /sys/devices/system/gpu/freq_table
In the above example you end up with the same end-result over the stock settings.
Valid clock frequencies are as follows: 54, 108, 160, 200, 266, 275, 300, 350, 400, 440, 500, 533, 600, 640, 666, 700, 733, 750, 800.
- volt_table outputs the voltages to the corresponding frequencies.
Pair-wise target setting: echo 533 1025 > /sys/devices/system/gpu/volt_table will change's 533MHz's voltage to 1025mV.
Whole-table echo in the same format as freq_table. Valid voltages are 600mV => x <= 1200mV.
- thresholds sets the two global threshold settings. echo 90 10 > /sys/devices/system/gpu/thresholds . Remember that the first is the up-threshold and the second is the down-differential. The down differential may not be higher than (99 - up value).
- min_freq and max_freq set the limits of the current DVFS policy. By default we're scaling from 160MHz to 440MHz (Same as stock).
echo 533 > /sys/devices/system/gpu/max_freq will enable the top limit to 533MHz and basically overclock the device.
echo 108 > /sys/devices/system/gpu/min_freq in the same way sets the lower limit.
25.3:
- current_freq shows the current frequency. This is if somebody likes to make a monitoring app or something.
- time_in_state shows the time spent in µS on each frequency step. Echo 0 to it (by default disabled) to disable it, 1 to enable monitoring, and any other numerical value to reset the timekeeping back to 0.
Perseus alpha24 (09/10):
Galaxy Note 2 source and kernel merge. Various platform fixes included from patching up from update5.
Fixed Mali GPU interface bugs relating to staycount, and lowered undervolt-soft limit down to 600mV.
Feature recap for new Note 2 users:
- Overclocking up to 1.8GHz and undervolting support through SetCPU. Note 2 users have a better quality CPU than Galaxy S3 users, so mind the default high voltages on those frequencies.
- GPU overclocking and undervolting support.
- A great amount of changes to improve battery life.
- Features which are in strikethrough in the changelog below do not work/are not ported on the Note 2, yet.
24.3 => Sharpness fix for the display included. Courtesy of hardcore.
24.4 => Removed Touch Boost in exchange for the Flexrate mechanisms. See below in changelog for more information.
Ported LCDFreq to the Note 2. See below in changelog for more information. The flickering is sadly still there on the Note 2.
Fixed undervolting below 850mV, previous undervolting below that value would be disregarded and 850mV would be applied in reality, even if it showed up the entered value.
Improved boot time by about 22 seconds: Fixed a major bug in the sensor hub firmware update logic, in the stock kernel and currently published sources the sensorhub firmware is being flashed over the current one on every boot, regardless if the payload firmware is the same as the current one. The update is about 130kB but it is done over the incredibly slow i2c bus, so this slowed down boot considerably. The reason was mis-labeling of the kernel firwmare version in the driver and failure to check if firmware was actually newer.
Perseus alpha23 (27/09):
Changed some auxiliary CPU clock dividers for frequencies 1600,1704,1800 MHz. These frequencies should use less power now and also should be more easily reached with more stability or lower voltage depending on your device.
Fixed CPUPower driver (Back from alpha20); this will now skew the reported processing capacity of CPU0 in the lower frequencies up until 500MHz to be 8 times greater than CPU1-3, what it does now is that the scheduler will even more migrate tasks onto CPU0 to avoid idle wakeups on the remaining CPUs, resulting in increased power efficiency. For high load > 500MHz, the driver reverts back to the default power configuraitons.
Reset the regulator configurations to their physical minima; you can now undervolt to 600mV on the GPU. Sorry I missed this before.
New feature: Dynamic Screen Frequency Scaling.
This decreases the display controller frequency in tandem with the CPU speed. Usually when you have low activity on the screen; i.e. low re-draw rates, then you mostly also have logically low CPU load. I wrote a scaling mechanic to switch between high display frequency (60Hz), and low display frequency (40Hz) in accordance to CPU scaling. This is tied in in the CPUFreq governor, in this case PegasusQ. We have three new governor configurables found in /sys/devices/system/cpu/cpufreq/pegasusq/ (Or alternatively just use SetCPU):
lcdfreq_enable: Enables or disables the mechanic, disabled by default.
lcdfreq_kick_in_down_delay: The amount of samples to wait on below the threshold frequency before entering low display frequency mode. Default value is 5 for now, a.k.a. in most cases 250ms unless accelerated flexrate is active on low load (fingers touching the screen), then depending on situation it might get as low as 62.5ms.
lcdfreq_kick_in_freq: The frequency threshold below which the low display frequency kick-in will be active. Default is 500MHz, and should probably stay as such, setting it higher will cause lags as we'd be using 40Hz in an interactive situation.
For the curious: I made a rudimentary time_in_state state accounting sysfs in /sys/devices/platform/samsung-pd.2/s3cfb.0/graphics/fb0/lcdfreq/time_in_state for testing purposes. Currently it shows wrong time values for 60Hz as the driver gets initialized before the high resolution timer, and I'll fix that later, but the 40Hz time statistics are correct.
Notice: There will be now conflicts between this and user-space controlled TwDVFS service/app. The service would limit screen frequency to 40Hz while using the camera app, this will be now overridden. I also thought the service would do more but I could not find it scaling for anything else than the camera, so it's pretty much useless in my mind, and you could theoretically remove it.
Feedback 23.3: This feature causes flickering on bright colours and low brightness. Enable it at your own will.
Changed the functionality to boost to 60Hz on any touch interaction, regardless of CPU speed.
Please provide feedback on fluidity and battery life.
Perseus alpha22 (22/09):
Update to update5 source code. Only compatible with Samsung Jellybean ROMs.
Stacks with my previous memory changes: total memory: 857mB for now.
Implemented timer slack controller.
Backported the scheduler NoHz load computation fixes, this should dramatically improve PegasusQ's hot-plugging decision making.
Further reduced Mali sampling rate down to 50ms and changes the default thresholds to more aggressive power savings and clear-cut scaling. Removed 10ms regulator switching latency. I measured a 10% battery improvement in GLBenchmark 2.1 Egypt Battery - 50% Brightness 60 FPS.
config.gz support.
Alpha21 is the same as above but without update5 and for ICS. This is the last kernel for ICS, I'll not longer support it.
Perseus alpha20 (9/09):
Gökhan Moral's port of Voodoo Sound implemented. Currently no configuration interface is available, so if you wish to play with the settings, refer to the sysfs interfaces in /sys/class/misc/scoobydoo_sound/ . If you wish to change the device name, you must do echo 0 > /sys/class/misc/scoobydoo_sound_control/enable , followed by an echo output to the same file with the target device driver name. You can use this to change the device path to /sys/class/misc/voodoo_sound/ and sub-sequentially make a certain configuration application work. Please do not ask me for support on the latter. You can disable the sound modifications completely by the same method, by of course not re-enabling it afterwards.
Changed the Wifi packet filter to block out all but mDNS multi-cast packets.
Increased mmc timeout for bad quality SD cards.
Perseus alpha19 (1/09):
Updated Samsung source base up to update4, includes changes to the Wifi driver and various other small fixes
Added ARM topology support for the scheduler to be able to use sched_mc levels. This should increase cpu idle power consumption by decreasing idle wake-ups. For the moment disabled by default, and cpu_power doesn't seem to correctly work.
Swap support.
mDNIe sharpening improvement, courtesy of hardcore.
Decreased Mali utilization timeout to 100ms down from 1s which improves reaction time on instant GPU loads (Lock screen is best example).
New valid GPU frequencies : 54, 108, 160, 200, 266, 275, 300, 333, 350, 400, 440, 500, 533, 600, 640, 666, 700 Mhz
Increased user-space memory by 48mB to have a total of 825mB useable RAM; this comes from reduced DMA memory spaces on the part of:
- The Mulfi Function Codec a.k.a. the hardware decoding and encoding unit memory space from 50176kB to 28672kB
- The camera interface imaging subsystem from 12080kB to 10240kB
- The front-camera firmware block-space from 15360kB to 14336kB
- The ION heap size for the Video4Linux driver from 71680kB to 48128kB
In the case of the ION/V4L and MFC heap sizes I determined it by setting a benchmark for all the HD sample videos listed here to not have any detrimental effect before and after the changes. Below 41mB is the size for which the Planet Earth birds scene at 1080p high profile 4.1 40mbps video starts to lag. Keep in mind that there is no way this would be considered normal quality as this is basically un-recoded Blu-Ray quality and most videos are vastly under this bit-rate.
I note that I also haven't found any detriment in use of the cameras including the modded 30mbps camera quality.
Disabled the Kies daemon, I see no point in it and it uses up memory uselessly. Obviously Kies won't work any-more, if you want you can start the service yourselves manually.
Perseus alpha18 (11/07):
Updated Samsung source base up to update3, includes various fixes to fuelgauge battery reporting on full charge, MHL code, video media drivers, Wifi driver updates, gyroscope, MAX77686 battery charger changes, increased max display brightness, a buttload of LCD panel changes, and changes to the pixel refresh rate driver (This thing is controlled by the TwDVFSapp by the way and decreases screen power consumption at runtime).
ro.secure=1 again now but with an insecure adbd as root included.
LFB ramdisk.
Compiled with Linaro 4.6.2 and some higher level optimizations.
Keep in mind that running the new kernel on older ROMs can cause some funny behaviour, so update your ROM if so.
Perseus alpha17 (9/07):
Rewrote flexrate request code for pegasusq: I apologize for releasing the previous version in the state that it was, shame on me.
Now upon receiving a flexrate request and active ones, the governor delays hot-plugging sampling logic so that accelerated sampling is being taken into account and hot-plug sampling is normalized for the standard sampling rate. All sub-samples are being averaged into a normal sized sample at the end of the normalized period. This no longer interferes with the runqueue read-outs as they were being reset too fast and generally accelerated hot-plugging in a bad manner.
Changed touchscreen flexrate requests to 12500µS sampling rates over 4 periods to synchronize with the default pegasusq sampling rate.
I consider this chapter to be done and a success as far implementing flexrates as a viable and working alternative to touch-boost to increase responsiveness without having the bad battery-life side-effects of the touch booster.
Performance governor is now core-aware, previously as no other hot-plugging logic was available, the governor would start with whatever number of online cores were available at that time and stay like that. This made Performance useless for it's designed purpose, that being bringing maximum performance. It now brings up all available cores online upon start and turns all additional cores back offline on governor stop. It is now by far the best and consistent governor for benchmarking.
Removed unused cpu_freq_up, cpu_freq_down, and several other flexrate related governor parameters in Pegasusq as they were either not used, or senseless.
Default Pegasusq parameters changed:
- Sampling-down factor reduced to 1 from 2, this caused reduced sampling speed upon reaching maximum frequency. It now scales (possibly down) faster.
- Frequency steps reduced from 40% to 21% of maximum frequency, this causes it to scale in 300MHz steps for the default maximum policy of 1400MHz. As we now have flexrates to scale faster I did not notice any negative effects on performance and this should help battery-wise on load-"spiky" applications, and in general.
- Increased runqueue-length thresholds for the hot-plugging logic by a flat 75 for all conditions. In my opinion and experience they were too low and caused to keep the cores needlessly online. This now reduces for "average low" use the online-time of the third core considerably.
- Increased the hot-plug frequency conditions for the 4th core.
Updated the kernel from upstream to 3.0.36.
Memcopy and string function improvements, won't bring any noticeable differences.
Compilier optimizations (Roughly the same as Ninphetamine's) are now in. VFP uses the NEON libraries now. I couldn't measure any increase in any synthetic benchmarks with this though.
LFB exFat modules.
Perseus alpha16 (3/07):
Disabled touchscreen touch booster; this previously locked the CPU frequency at 800MHz, memory interface to 400MHz and bus frequency to 200MHz at any time the finger touched the screen.
Implemented flexrate capability into pegasusq; additionally added a frequency threshold above which flexrate requests are ignored. Currently this is set at 800MHz but is configurable in the governor tunables.
Enabled quality of service requests in the touchscreen driver, this currently triggers a flexrate request at a sampling period of 15ms over the governor default of 50ms, and over 5 periods, giving 75ms of heightened reactivity. It also sends a direct memory access throughput quality of service request to the the linux power management quality of service interface to guarantee a 266MHz bus frequency for 142ms. Still need to check if that the last part works correctly.
Perseus alpha14 (21/06):
Only Mali platform changes.
Remove Samsung integrated checks on in the Pegasus platform that prevented the GPU control interfaces to work. Overclocking, undervolting, and the rest now properly work.
Removal of the CPU frequency lock to 1200MHz if the GPU is at 440MHz, this is excessive as 3D load heavy applications usually do not tax the CPU that far, and is an unnecessary power consumption burden.
The thermal control unit temperature throttling causes to fix the voltage to a fixed value when throttling is in place; this is useless considering frequency is not limited, making the whole thing senseless. Thus removed.
Perseus alpha13 (20/06):
Rebased sources on a Linux branch for commit completedness. All commits reapplied and cleaned. New repo.
CIFS included as module
Busybox removed. This should be part of the ROM.
Perseus alpha12 (14/06):
Added enhanced init.d support as per dk_zero-cool's implementation.
SHA-1 improvements
Added exception to the module loading logic for the exFat driver module thus making it work. (Credit to gokhanmoral)
Perseus alpha11 (10/06):
ro.secure=0
Recovery renamed as busybox in /sbin. I'll compile a proper busybox later on, or remove it alltogether when a recovery with autoinstall is released by CF or somebody else.
Perseus alpha10 (8/06):
Overclocking up to 1800MHz. Voltages in ASV table are somewhat scaled up until 1600MHz, after that you're on your own and have to optimize yourself.
Intel claims maximum sustainable safe voltage for 32nm HKMG to be 1.4V, above that may cause electron migration to the silicon and permanently deteriorate your chip. 1700 and above only for avid overclockers and benchmark freaks. Credit to tvanhak for playing lab rat with his phone.
Samsung frequency limitation removed to scale above 1400MHz, full credit goes to Gokhanmoral for finding this hack in the kernel as it is in a very sneaky location.
Perseus alpha7 (5/06):
Reduced regulator voltage initialization minimum to 600mV, you can now undervolt that far. Be aware of crashes.
Added SIO scheduler
Some network and CRC related patches
Perseus alpha6 (4/06):
UV_mV_table support, apps like SetCPU work now.
If you have a voltage set at for example 1187500µV the output will be rounded up to be displayed at 1188mV. If you set a voltage non multiple of 12.5mV then for example, 1190mV, it will round it to the nearest valid step, being 1187.5mV. UV_uV_table is there for finer grained control but no app suports that yet.
Perseus alpha3 (4/06):
Mali: disable state tracking
Mali: GPU frequency, scaling and voltage control
Governor pegasusq: make up_threshold_at_min_freq and freq_for_responsiveness configurable values. This is the reason the Galaxy S3 is so smooth, it has super aggressive scaling values for the governor until default 500MHz.
Enabled 1500MHz per defconfig and added voltage values to ASV table for it
Added UV_uV_table for voltage control on the CPU; this is not compatible for any programm which supports undervolting right now, we need UV_mV_table for that and since we have 12.5mV steps being fed to Vdd it's not compatible for now.
Boot partitions are made visible.
Reserved. (Variant downloads moved to post 2)
Wihoe first kernel .. gonna flash this baby when im home from work!
Sent from my GT-N7100 using XDA Premium HD app
Testing at 1800 with reduced voltages at the moment
Sent from my GT-N7100 using Tapatalk 2
All right, gona try it soon and it performed well on the S3though my cpu crashed all the time at 1800 Mhz.
gee2012 said:
All right, gona try it soon and it performed well on the S3though my cpu crashed all the time at 1800 Mhz.
Click to expand...
Click to collapse
So far so good. Did drop the voltages to 1300 tho but gonna give it some time to run
Sent from my GT-N7100 using Tapatalk 2
sswagonman said:
So far so good. Did drop the voltages to 1300 tho but gonna give it some time to run
Sent from my GT-N7100 using Tapatalk 2
Click to expand...
Click to collapse
Did you undervolt bu -75 or -100, ask this cause i get my GN2 tomorrow so can`t do anything atm
Downloaded twice. ..installation aborted. ... Does it happen only to me?
sent with my beast N7100
Use the .tar if the zip didn't work, I'll fix it in a few hours.
Wow. This must be tested
Sent from my GT-N7100 using Tapatalk 2
Ferranza said:
Downloaded twice. ..installation aborted. ... Does it happen only to me?
sent with my beast N7100
Click to expand...
Click to collapse
edit the update-script
find the line and edit to this will fix the problem
write_raw_image("/tmp/boot.img", "/dev/block/mmcblk0p8")
** for some reason, the back and menu key will not function at all
Onepagebook said:
edit the update-script
find the line and edit to this will fix the problem
write_raw_image("/tmp/boot.img", "/dev/block/mmcblk0p8")
** for some reason, the back and menu key will not function at all
Click to expand...
Click to collapse
I managed to upload the wrong CWM version, I reuploaded and both issues fixed.
Flashed thru Mobile Odin. Worked flawless.
Sent from my GT-N7100 using Tapatalk 2
Ok so now I can install it?
sent with my beast N7100
Have not undervolted yet but at 1800 this is incredible
Sent from my GT-N7100 using Tapatalk 2
Reb0rn said:
Flashed thru Mobile Odin. Worked flawless.
Sent from my GT-N7100 using Tapatalk 2
Click to expand...
Click to collapse
No flash counter increase on Mobile Odin Pro 3.4.0?
That was fast Andrei, like i told you befor... so Damn nice to see your kernel here.
Will get my replacement device tomorrow and then I will try it out right away.
Updates
Lollipop: The attached archive named camcorder_audio_fix_plus_stereo_playback_LMY47D_v1_1.tar.gz or this Aroma installer is fully supported on any AOSP-based Lollipop build greater than or equal to 5.1
M-Preview: The "simple" fix (without noise suppression) offered by this Aroma installer should work any of the M-Preview builds. The "advanced" mod, however, is incompatible with M-Preview builds.
October 8, 2015: Full Marshmallow support available here
August 26, 2016: Nougat support for simple fix available here
The Problem
The audio of a camcorder recording made by the Nexus 5 has often been described as "under-water" or "bubbly":
Speech signals sound distorted and low-level background sounds fade in and out. Overall, an embarrassingly bad audio quality.
As it turns out, the audio recording is fed to a noise suppression algorithm that is way too aggressive.
Also, the Nexus 5 is not able to record anything useful in very loud acoustic environments, such as a concert.
The mod presented here is aimed to fixing these issues.
Simple fix: Turning off noise suppression
I found a very simple way to turn off noise suppression altogether. All this fix does is to select a different audio device that bypasses noise suppression.
Unfortunately, this change requires modification of a system library which means that your phone needs to be rooted.
To experience the effect of the simple fix you can listen to some audio samples here.
Advantages of this "simple" version of the mod
- the recording is now devoid of any signal processing, i.e. no additional distortion is being introduced to the sound
- the mod should work with pretty much any Lollipop AOSP-based ROM. Separate mods are available for CM11 and CM12, see link below.
- the simple fix should not interfere with any other app
Disadvantages of this "simple" version of the mod
- since noise suppression has been disabled, the (white) noise that the acoustic front-end (microphone, preamp, analog circuitry) of the Nexus 5 produces is now very audible. While I do not see this a problem in high-noise and/or outdoor environments, the high level of white noise can be problematic in quiet environments
- by default, the volume of the recorded sound is now lower than stock. Refer to the section "Changing the microphone gain" below for more details
- aMGC (see below) is not supported
A new simpler "simple" version of the mod that does not require modification of a system library can be found here
Advanced Fix: Applying moderate noise suppression
After having spent a significant amount of time tinkering with the Android audio stack, I found a way to apply a moderate amount of noise suppression to the camcorder signal.
This new fix makes use of the webRTC noise suppression algorithm available in AOSP (but it was missing the required plumbing). For now, I'm giving you guys two options to play with: 6 dB and 12 dB of suppression.
Note that although 6dB of noise suppression is generally considered as "low", I can still hear some artifacts, but they are significantly reduced when compared to the stock experience. (The stock library adds about 20 dB of noise suppression)
For my taste 12 dB adds too much distortion, but it may fit the bill for some of you.
Keep in mind that webRTC's noise suppression algorithm has been optimized for speech signals and, as a result, other types of signals (music, nature sounds etc) may suffer from some distortion.
To experience the effect of the advanced fix, you can listen to some audio samples here.
Advantages of the advanced fix
- users now have the option to select the level of noise suppression that suits their needs.
I'm personally torn between no noise suppression and 6 dB of noise suppression due to some (barely audible) distortion still present when 6 dB of noise suppression is applied.
- aMGC is supported (see below)
Disadvantages of the advanced fix
- this fix may not work with ROMs other than Stock Android 4.4.4/5.0.x/5.1.x as fundamental changes to the Android audio subsystem (audioflinger) were necessary to feed audio to the built-in effects processor
- there may be problems with this fix in combination with other audio mods (e.g. DSP Manager). Please report back if you experience problems with this fix and other audio mods on stock Android
Known issues
- having either "hotword detection from any screen" or "touch sounds" enabled results in the audio bypass the effects processor, which means that either of these features will disable noise suppression completely!
Installation instructions:
Please refer to the README provided with the attached archive.
assisted Manual Gain Control (aMGC)
The Problem
By default, the microphone setup used for camcorder recordings is tuned to be fairly sensitive. The idea is that distant sources are still recorded with sufficient level. The disadvantage is that loud signals, such as music or screaming kids, will cause a great deal of distortions, thereby rending recordings in noisy environments virtually useless. Android does not offer any way to adjust the microphone gain by the user.
In looking into this issue, I have played around with automatic gain control (AGC) as offered by a webRTC component that ships with Android. I found that AGC as implemented (optimized for speech signals) is not suitable for camcorder recordings as it more often than not causes wild swings of level fluctuations.
An attempt to arrive at a solution
The idea as implemented in this "app" (more accurately a background service) is to show a UI with gain control during a camcorder recording along with a VU meter to assist the user to adjust the gain during a particular recording. I'm calling this approach assisted manual gain control (aMGC).
The attached apk for aMGC has been generated directly from a Tasker project by using the Tasker App Factory app.
A Tasker project that can be imported into your own Tasker setup is also supplied.
Note that the minimum API level for this app is 21. Hence, it is only compatible with Android > 5.0
The app does the following:
pretty much nothing if you click on the icon, as it is a service that starts automatically on boot. However, you may need to start it manually in case Android decides to kill it.
it kicks in whenever the Google Camera launches
it observes the state of the soundcard; if the microphone is opened (i.e. a camcorder recording is started), it displays a small floating and blocking UI in the lower right-hand corner of the screen with which the microphone gain can be adjusted
it uses the LED to display a VU meter, going from faint green (very low signal level detected) to yellow to orange to red (very high signal level detected)
by default it uses the gain as defined in mixer_paths.xml (indicated as 0 dB in the UI). Each short-press on the "down" button decreases the microphone gain by 6dB; a long-press decreases the gain by 12 dB; similarly each press on the "up" button increases the gain by 6 dB and a long-press by 12 dB. Additional gain is limited to +12 dB
Whenever a recording is stopped, the UI disappears and the LED VU meter stops. When the record button is pressed again, everything starts over again with the default values from mixer_paths.xml. Note that it is an Android implementation detail that mixer_paths.xml edits need a system reboot to be applied.
Prerequisites
latest "advanced" camcorder audio mod available here
tinymix (attached; uncompress, copy to /system/bin, and make executable)
NEW: all attached shell scripts, see shell_scripts.tar.gz; unpack, create a directory /data/local/tmp/camera, copy all scripts to that directory, and make all files executable. I had originally thought that Tasker automatically incorporates all shell scripts into the apk, but it does not. Currently, aMGC expects these files to reside in /data/local/tmp/camera . I'll try to fix that in a future revision of the app, by integrating the shell scripts into Tasker.
app needs root privileges
busybox
app needs Accessibility permissions. After installation go to Settings->Accessibility and enable CamcorderMGC. Unfortunately, this permission is required to detect Camera start/stop events. Don't worry, I'm not doing anything nasty
Android >= 5.0
If you are using Tasker (also needs Accessibility privileges) you need to run at least version v4.6. Running the attached Tasker project, i.e. CamcorderMGC.prj.xml, is generally preferred over using the app. Note that you will also need to copy the attached shell scripts to /data/local/tmp/camera when using the Tasker project.
Usage
Hit record and observe the VU meter. If the UI and VU meter do not start you may need to start the app manually as Android may have killed it.
You want the color of the LED to remain yellow/orange. Long periods of red means bad clipping. In that case you may want to lower the gain either gradually (6 dB steps) in moderately noisy environments or more aggressively (12 dB steps) in noisy environments until the LED keeps blinking yellow or orange. Short bursts of red are probably OK. I need you guys to give me feedback on that.
If the levels seem too low after a recording has been made, simply boost the gain by using a decent video editing app on your PC.
Known issues/limitation
Each interaction with the UI takes a couple of seconds to complete. Short-press or long-press the buttons once and be patient for the task to complete. Once completed, the current gain adjustment with respect to the default levels will be displayed.
aMGC currently does not work as expected when hotword detection is allowed from any screen.
aMGC currently does not work when "Touch sounds" are enabled in Settings -> Sound & notification -> Other sounds
Whenever the user changes the microphone gain(s) during a recording a very short click may be audible while the codec (WCD9320) changes the gains as requested. This occurs due to the discontinuity in the audio signal while the gain modification is being applied. Conventional remedies, such as cross-fading cannot be applied as the actual audio data is not available to the aMGC method. For "critical" recordings I recommend running a quick "sound check" first to find the appropriate gain and then quickly apply it at the onset of the actual recording. I suggest to be conservative with the gain as an overall low gain can be easily corrected for by post-processing while excessive gain may result in irreparable distortion.
Installation instructions:
Please refer to the separate README provided with the attached archive.
Aroma installer
Thanks to @spacetaxi there are extremely flexible Aroma installers available for added convenience.
The latest installer for Lollipop < 5.1.0 can be found here and the one for Lollipop 5.1 here.
The installer for KitKat (now deprecated) can be found here
Confirmed working ROM/kernel setups
stock Android 4.4.4/5.0.x/5.1 with stock kernel
Cataclysm (Jan 23) with Code Blue kernel
Cataclysm (Jan 23) with Cataclysm kernel
CM11 (simple fix only, no aMGC)
CM12 (simple fix only, no aMGC)
stock Android 4.4.x with stock kernel (no aMGC)
Additional mods
In this section I describe mods that don't have anything to do with camcorder recordings, but still appear (or will be appearing) in the modified mixer_paths.xml
Stereo playback
Based on prior work by @sshafranko (but originally discovered by @dontbelive) I enabled "true" stereo playback on our device by turning on and tuning the earpiece loudspeaker.
Refer to this post for details.
Sidetone for telephony
Closed-type headphones, noise canceling headphones, and IEM earphones are very good at shutting out environmental sounds. Unfortunately, they also block your own voice. While wearing these headsets you are actually hearing the sound of your own voice via means of bone conduction and resonances of head cavities. It sounds extremely low-pass filtered and it is very difficult to conduct a conversation while wearing headphones. This is where sidetone comes in. Please refer to this post for details.
Using external microphones
A tweak to the main mod is presented here, which allows an external microphone (via headset port) to be used instead of the built-in one. An important advantage of doing so is to be able to utilize a better-quality microphone. (The ultimate improvement in sound-quality can be achieved by using a (mono/stereo) microphone that connects via a good-quality preamp and ADC to the phone's USB port, if supported by an app.)
Additional information
Changing the microphone gain
Background:
The microphone path used by this mod is "voice-rec-mic-mod", which is derived from "voice-rec-mic" already present in the stock version of /system/etc/mixer_paths.xml .
The default microphone gain is set to 97 ("DEC6 Volume"). If one feels that microphone "sensitivity" is insufficient, this gain can be increased significantly. According to ALSA mixer data, the maximum level can be set 124. Measurements have shown that each "tick" (integer increase of this value) adds about 1 dB of gain).
You can actually also modify the "ADC1 Volume" parameter, which ranges from 0 to 19 (and adds about 1.5 dB per tick), but I have not seen any real advantage of modifying this value over the other in my tests. The abbreviation "ADC" (Analog-to-Digital Converter) suggests an analog gain which would result in a better
SNR (signal-to-noise ratio) if that gain is adjusted rather the one associated with DEC (which for sure is a digital gain and thus has no effect on SNR if used inside the signal's full digital scale). My tests, however, have shown no advantage of using the "ADC1 Volume" setting in terms of SNR.
Of course, there is a tradeoff between microphone gain and background noise, i.e. higher gain results in more audible microphone/preamp ("white") self-noise. As a matter of fact it is this noise that the original library tries to fight with its poorly implemented/configured noise suppression algorithm.
Static modification of microphone gain:
- method 1: The gain can easily be changed by editing the new mixer_paths.xml file directly via a file browser, like Root Explorer. The values can range from 0 to 124. Your phone needs to be rebooted for the changes to take effect.
- method 2: run the Aroma installer
Dynamic modification of microphone gain using tinymix:
Once the recording has started, the microphone gain can quite easily be modified with the help of the attached tinymix binary, which can be built from the AOSP tree.
The syntax (after it has been uncompressed), copied to, e.g., /system/bin, and made executable is:
> tinymix "DEC6 Volume" X
where X=[0,124]. Again, there will be a tradeoff between microphone gain and noise amplification.
The big caveat is that the gain is reset to the one listed in the file /system/etc/mixer_paths.xml every time a new recording is started.
If you are running the "advanced" mod, then you may want to try aMGC which helps you adjust the gain depending on the acoustic environments (see the section on aMGC).
Links to the simple mod for CM
Go here for CM11-based ROMs
and here for a CM12 (and CM12.1)-based ROMs
Thoughts on in-call voice quality
As the question regarding in-call audio quality has come up a few times, let me elaborate on my findings:
Most modern smartphones use two microphones when making phone calls. Dual-microphone processing can be very sensitive to the relative position of the talkers mouth and the microphone, in particular in varying background noise scenarios.
Especially when the main microphone on the N5 (the one behind the grille) is far away from the mouth the local talker may be mistaken for background noise and, hence, get suppressed.
As dumb as it sounds, try to hold your phone "right" when making calls, i.e. talk directly into the microphone and try not to move the phone much.
A second very important "good practice" suggestion is to keep the loudspeaker volume as low as possible and try to talk in low background noise environments (I know that the latter one is not always possible). The reason is the rather nasty subject of double-talk.
When a phone detects a double-talk situation, i.e. a loud RX signal combined with a strong TX signal (talker + background noise), the AEC (acoustic echo canceler) will typically start "clipping" the near-end speech, which results the other end not being able to hear you.
Other than these two basic suggestions, there are a couple of things a brave soul can try to fight this issue.
Note there is no (and possibly never will be a) real fix without Qualcomm's and LG's intervention. I'm currently using what's
behind door #2 below with success...
1. Changes in build.prop (not an endorsed workaround)
========================================
consider this change
- persist.audio.dualmic.config=endfire
+ persist.audio.dualmic.config=broadside
What this does is change the dual-microphone algorithm to an alternate one. In my (limited) testing, however, "broadside" was worse than the "endfire" configuration. Actually, I never got many complaints about other people not being able to hear me using "endfire"
However, it may work for you. If it does, great, and you don't need to move on to try other stuff, such as another change:
- persist.audio.dualmic.config=endfire
+ persist.audio.dualmic.config=none
This change turns off dual-microphone processing altogether. The big caveat is, however, is that this change seems to disable other vital signal processing as well, in particular AEC.
Other issues I have seen with these two changes is that the first call after a reboot is often "bad", which can be fixed by quickly switching to speakerphone mode and back. Not good.
2. A very complicated workaround (which works for me)
=========================================
As I mentioned earlier in the thread, I spent a lot of time trying to fix the in-call RX distortion issue when recording from the line.
I found a workaround that works for me that may partially address the issue of occasional low TX level as well. I say partial since low TX level may be caused by both the dual-microphone processing as well as the AEC in double-talk situations. This workaround only addresses (turns off) the dual-microphone processing while still enabling AEC as well as some noise suppression. Low TX levels in double-talk situations can only be improved by Qualcomm, but somewhat alleviated by an educated user (see suggestions above).
The fix requires:
* turning off dual-microphone processing (persist.audio.dualmic.config=none in build.prop)
* custom AOSP kernel (3.4.0-gd59db4e) that allows for injecting proper (?) audio calibration data via Qualcomm's acdb interface, which enables AEC as well as single-channel noise suppression
* a bunch of Tasker scripts
* a shell script
* a binary that commits the calibration data to the kernel/CPU upon a system reboot, or when needed as determined by the Tasker and shell scripts
Ultimately, in finding a fix for this issue, I got stuck at the lack of documentation of Qualcomm's audio interface.
My solution is just a huge hack to address a problem that really can only be fixed by Qualcomm and LG (and maybe Google) as
all processing during cellular calls is done by Qualcomm deep within the MSM/DSP. It is my understanding that the signal processing within that chip is controlled by some of the proprietary vendor blobs.
Some gory details
Up until now, the device identifier used for camcorder recordings in the audio HAL, i.e. audio.primary.msm8974.so, has been selected
as "SND_DEVICE_IN_VOICE_REC_MIC" (while stock uses the "CAMCORDER" device identifier with disastrous quality consequences).
Many people have been observing that the Nexus 5 is unable to produce any useable recordings in loud acoustic environments, in particular
club or concert hall settings. After spending a lot of time doing detective work, I found that the problem can be traced to a high-pass filter (HPF)
being active in either the codec itself (WCD9320) or the main chipset (MSM8974) while most available device identifiers are used, including
"CAMCORDER" and "SND_DEVICE_IN_VOICE_REC_MIC". I'm suspecting two problems with this HPF. One, I think that the HPF itself may be causing
distortions. Second, by filtering out low frequencies, the microphone level estimate that I'm performing inside the audioflinger service is biased in that it
cannot take into consideration the low frequencies that actually hit the analog-to-digital converter, which will eventually cause it to clip.
I found that the "ACDB_ID_VOICE_DMIC_EF_TMUS" identifier in the audio HAL disables the HPF filter. Now the level estimate that is being used by
aMGC is bias-less. Clipping can be properly detected and action can be taken with the aMGC UI to appropriately lower the microphone gain as needed.
An explanation why low-frequency clipping is much worse than clipping at higher frequencies:
In general, clipping (when a signal exceeds full-scale representation of a digital system) causes the introduction of even-order harmonics.
Assume you want to record a 50 Hz sinusoidal signal. Clipping of that signal will cause the recording to not only include a 50 Hz tone (0-th order harmonic),
but also a 150 Hz tone (2-nd order harmonic), a 250 Hz tone (4-th order harmonic), etc. In all, more than a hundred additional tones will show up in your
recording, albeit at progressively lower levels than the 0-th order harmonic. That original pure sine wave now sounds more like a "rectangular wave".
Imagine what happens when a more complex low-frequency signal is getting clipped. The recording is ruined.
On the other hand, a clipped 1000 Hz sinusoidal signals will "only" produce seven additional harmonics in the frequency range that the Nexus 5 is capable
of recording (approximately less than 16 kHz). Don't get me wrong, clipping is bad no matter the frequency (and a professional avoids clipping like the plague),
but the effect is much more dramatic when clipping is happening at low frequencies.
Thanks
Big thanks go to @spacetaxi for the Aroma installers and @skvalex without whom I would probably never have looked into any of this.
XDA:DevDB Information
[MOD] [ROOT] Camcorder Audio Quality Fix with Stereo Recording and Playback Support, Device Specific App for the Google Nexus 5
Contributors
chdloc
Version Information
Status: Testing
Created 2015-03-06
Last Updated 2015-03-06
So you say you found a signal path that bypasses noise suppression, but the modification is increasing the gain? Is their a specific gain value you are using that happens to bypass noise suppression?
Aroma installer package of chdloc's fix for Android 4.4.4 stock / AOSP-based roms
This is the aroma installer package of chdloc's camcorder audio fix for 4.4.4 stock / AOSP-based roms. Other installers of the fix are available for Android 5.1 (see post #627), Android 5.0 (see post #235) and for CM11 (see post #56).
Flashing the installer, you will get four options:
Install Audio Fix - simple: no noise suppression, bitrate 288 kbps
Install Audio Fix - advanced (6 dB): 6 dB noise suppression, bitrate 288 kbps
Install Audio Fix - advanced (12 dB): 12 dB noise suppression, bitrate 288 kbps
Install Stock KTU84P Audio: 20 dB noise suppression, bitrate 96kbps (stock audio libs and config from build KTU84P)
So if you are using Google's stock firmware build KTU84P, option 4 will revert the system files changed by options 1-3 (audio libs and config files) to their stock versions.
If you are using a different firmware build or if you've changed the config files and want to be able to revert the files to their current state, please make a backup of the system partition by using the recovery (CWM / TWRP) prior to installing this zip. Then you can just restore the system partition if you don't like the changes.
Every option will overwrite the following files:
/system/etc/media_profiles.xml
/system/etc/mixer_paths.xml
/system/lib/hw/audio.primary.msm8974.so
/system/lib/libaudioflinger.so
/system/lib/soundfx/libaudiopreprocessing.so
/system/vendor/etc/audio_effects.conf
By the way, you should make a backup of the system partition in any case! There's always a (small) risk that something goes wrong when flashing a zip. Anything you do, you are doing at your own risk. :fingers-crossed:
And please do not forget to post your experiences with this fix!
Happy flashing!
m52 power! said:
So you say you found a signal path that bypasses noise suppression, but the modification is increasing the gain? Is their a specific gain value you are using that happens to bypass noise suppression?
Click to expand...
Click to collapse
My mod is not changing the externally controllable gain at all by default. It gives you, however, the option
to change the gain without affecting any other apps.
initial testing seems to be working well, gonna do some more this evening & see how it goes. thanks for the share
Natural video sound again on my N5
After Google messed up the N5's camcorder audio in 4.4.3 and 4.4.4, I was getting by using Snap Camera with alternate mic enabled, but in all honesty the audio quality was still nowhere near as good as some of the phones I owned even 6 or 7 years ago,
Now I don't know exactly what this mod does, but my videos sound like they should again so big thanks to chdloc for the fix and spacetaxi for the aroma installer.
spacetaxi said:
Here I'm posting the up-to-date aroma installer package for chdloc's fix. I think he will refer to it from the first post as soon as he is online again. Happy flashing!
Click to expand...
Click to collapse
Any chance you could post a stock revert, just in case, please?
RussianBear said:
Any chance you could post a stock revert, just in case, please?
Click to expand...
Click to collapse
Check the aroma installer .zip. If I understood right it should be able to do the reverting. So just simply flash the file and you'll have an option to revert.
Does this mod do anything to fix the in call audio problem?
Could you possibly make a version for the L Preview? Thanks
RussianBear said:
Any chance you could post a stock revert, just in case, please?
Click to expand...
Click to collapse
rockknee said:
Check the aroma installer .zip. If I understood right it should be able to do the reverting. So just simply flash the file and you'll have an option to revert.
Click to expand...
Click to collapse
I've updated post #3 to make this clearer.
YES, this really does work! No bubbly-underwater like sound while recording video.
Now, you clearly know how to deal with libs and all. Any possibility you could fix dark video recording in low light on post 4.4.1 update? The 4.4.1 update prefers fast shutter speed to keep the framerate in low light, resulting in really dark night videos without flash. In 4.4, the camera was sluggish, but chose slower shutter speeds in video and though the framerate was 15-20 fps in darkness, you could actually see something. Like on an iphone and other phones recording in the dark.
Thank you.
Works on MIUI
Thank you for your mod!
I tested it on latest MIUI - and WORKs! It's based on 4.4.2.
Sound is now more consistent - before was choppy.
TNX... again!
Maxamillion said:
Does this mod do anything to fix the in call audio problem?
Click to expand...
Click to collapse
No, this mod only addresses the audio quality when using the camcorder.
Are you referring to the RX distortion issue when running CallRecorder or a similar app that records calls from the line?
If so, I do have a separate mod that is not for the faint of heart. You will need a custom kernel and a bunch of Tasker scripts to bypass the problem. Although the mod comes with a downside (it turns off dual-microphone processing), I'm running it without an issue.
PM me if you would like to give it a spin...
usaff22 said:
Could you possibly make a version for the L Preview? Thanks
Click to expand...
Click to collapse
I just downloaded the L Preview code tree and the sources that need to be modified for the mod have not changed.
There is a good chance this mod will work without any modification. Just try it and report back...
serzhanja said:
Now, you clearly know how to deal with libs and all. Any possibility you could fix dark video recording in low light on post 4.4.1 update? The 4.4.1 update prefers fast shutter speed to keep the framerate in low light, resulting in really dark night videos without flash. In 4.4, the camera was sluggish, but chose slower shutter speeds in video and though the framerate was 15-20 fps in darkness, you could actually see something. Like on an iphone and other phones recording in the dark.
Click to expand...
Click to collapse
I know how to deal with audio (I do this for a living) and I have some programming skills. Video is a whole different beast and I, unfortunately, don't have the time to work on video processing.
Hi,
can you tell me which lines/values are changed in your version of the mixer_paths.xml file compared to the stock version? Because I already have made some manual changes to my mixer_path file and don´t want to lose them.
Thanks,
Kusie
Kusie said:
Hi,
can you tell me which lines/values are changed in your version of the mixer_paths.xml file compared to the stock version? Because I already have made some manual changes to my mixer_path file and don´t want to lose them.
Thanks,
Kusie
Click to expand...
Click to collapse
I just uploaded a patch file for ROM devs to the OP, but basically just add the following path to your /system/etc/mixer_paths.xml :
<path name="voice-rec-mic-mod">
<path name="handset-mic" />
<ctl name="ADC1 Volume" value="15" />
<ctl name="DEC6 Volume" value="88"/>
</path>
Thanks, chdloc. Your mod works awasome! 9 months of useless video from nexus 5 is over. Greate job, man!
-Stakka- said:
Thanks, chdloc. Your mod works awasome! 9 months of useless video from nexus 5 is over. Greate job, man!
Click to expand...
Click to collapse
Did I read the OP right that this doesn't work on CM 11?
MrObvious said:
Did I read the OP right that this doesn't work on CM 11?
Click to expand...
Click to collapse
That's right. CM has made extensive changes to the audio subsystem, which would require a merge of the CM code tree
with the patch that I added to the OP.
I'd be happy to work with the CM team to make this mod available for CM 11 users.
I tried the aroma installer and it worked perfectly
awesome works guys !!
The cam sound is better than ever on the N5
I ported a few codes into the Nokia Recorder app v8.1030.40 to enable support for OZO audio recording. I've only tested this in my Nokia 7 Plus, but it might work in other OZO-supported devices.
Changelog:
- Added spatial recording support: ACC recording format (screenshot 2) now records with spatial audio recording by default.
- Changed app theme color: just to differentiate it from the original base app.
NOTES: To make the most of the spatial recording feature, I forced Surround mode in this mod, which means all three microphones are used at once. Since this feature is for video recording by default, its full potential can be maximized in landscape mode (since the microphones are oriented vertically, putting the phone in landscape mode allows for differential left and right audio channels). Here, I forced the orientation such that the left audio channel is oriented at the top portion of the phone, and the right audio channel at the bottom. So for accurate audio channels, I recommend orienting the phone in landscape mode with the charging port on the right hand side (like recording a video). Of course if it doesn't matter to you that much, you can orient the phone however you like; audio quality is good, nevertheless. Enjoy recording audio in high quality!
Download:
voicenote_8.1030.40_surround.apk
P.S. I humbly request everyone to please do not spam with "add the feature/support to GCam" etc. etc. I've spent 4 days to figure this out and make it work, and I need a break right now. Cheers!
back.rider555 said:
P.S. I humbly request everyone to please do not spam with "add the feature/support to GCam" etc. etc. I've spent 4 days to figure this out and make it work, and I need a break right now. Cheers!
Click to expand...
Click to collapse
It work on n7 plus ta-1046,nice work keep it up
When this device was released, my PRIMARY purpose to buy this phone was to use OZO audio to record songs !!!
THANKS A LOTT !!
Kudos to you Sir!
Doing Nokia's (well, HMDs work in fact), but nevertheless greatly appreciated
Many thanks. [emoji16]
Work great on my Nokia 5 (pie).
back.rider555 said:
I ported a few codes into the Nokia Recorder app v8.1030.40 to enable support for OZO audio recording. I've only tested this in my Nokia 7 Plus, but it might work in other OZO-supported devices.
Changelog:
- Added spatial recording support: ACC recording format (screenshot 2) now records with spatial audio recording by default.
- Changed app theme color: just to differentiate it from the original base app.
NOTES: To make the most of the spatial recording feature, I forced Surround mode in this mod, which means all three microphones are used at once. Since this feature is for video recording by default, its full potential can be maximized in landscape mode (since the microphones are oriented vertically, putting the phone in landscape mode allows for differential left and right audio channels). Here, I forced the orientation such that the left audio channel is oriented at the top portion of the phone, and the right audio channel at the bottom. So for accurate audio channels, I recommend orienting the phone in landscape mode with the charging port on the right hand side (like recording a video). Of course if it doesn't matter to you that much, you can orient the phone however you like; audio quality is good, nevertheless. Enjoy recording audio in high quality!
Download:
voicenote_8.1030.40_surround.apk
Click to expand...
Click to collapse
But how OZO VIDEO record
Steps please
Why does it require phone permission?
Sparker0i said:
Why does it require phone permission?
Click to expand...
Click to collapse
This is to pause recording with incoming phone calls.
Thank you very much, this will be very helpful because most recording apps doesn’t utilize Nokia’s ozo audio. Nokia microphones are awesome!
I'm curious how you figured it out. Is there some Nokia API documentation somewhere or is it just a matter of enumerating device capabilities and trying the various options? Is is an Java API or do you need to call ioctl on some device?
Would you be able to post a code snippet?
back.rider555 said:
I ported a few codes into the Nokia Recorder app v8.1030.40 to enable support for OZO audio recording. I've only tested this in my Nokia 7 Plus, but it might work in other OZO-supported devices.
Changelog:
- Added spatial recording support: ACC recording format (screenshot 2) now records with spatial audio recording by default.
- Changed app theme color: just to differentiate it from the original base app.
NOTES: To make the most of the spatial recording feature, I forced Surround mode in this mod, which means all three microphones are used at once. Since this feature is for video recording by default, its full potential can be maximized in landscape mode (since the microphones are oriented vertically, putting the phone in landscape mode allows for differential left and right audio channels). Here, I forced the orientation such that the left audio channel is oriented at the top portion of the phone, and the right audio channel at the bottom. So for accurate audio channels, I recommend orienting the phone in landscape mode with the charging port on the right hand side (like recording a video). Of course if it doesn't matter to you that much, you can orient the phone however you like; audio quality is good, nevertheless. Enjoy recording audio in high quality!
Download:
voicenote_8.1030.40_surround.apk
Click to expand...
Click to collapse
is not installing on my phone
back.rider555 said:
I ported a few codes into the Nokia Recorder app v8.1030.40 to enable support for OZO audio recording. I've only tested this in my Nokia 7 Plus, but it might work in other OZO-supported devices.
Changelog:
- Added spatial recording support: ACC recording format (screenshot 2) now records with spatial audio recording by default.
- Changed app theme color: just to differentiate it from the original base app.
NOTES: To make the most of the spatial recording feature, I forced Surround mode in this mod, which means all three microphones are used at once. Since this feature is for video recording by default, its full potential can be maximized in landscape mode (since the microphones are oriented vertically, putting the phone in landscape mode allows for differential left and right audio channels). Here, I forced the orientation such that the left audio channel is oriented at the top portion of the phone, and the right audio channel at the bottom. So for accurate audio channels, I recommend orienting the phone in landscape mode with the charging port on the right hand side (like recording a video). Of course if it doesn't matter to you that much, you can orient the phone however you like; audio quality is good, nevertheless. Enjoy recording audio in high quality!
Download:
voicenote_8.1030.40_surround.apk
Click to expand...
Click to collapse
Can you upload ozo video recorder
Please
j€nish said:
Can you upload ozo video recorder
Please
Click to expand...
Click to collapse
It's stock Nokia camera ??*
Thanks for the great work and for sharing. Installed fine on my Nokia 8. Will do some test recordings and listen with headphones, the only way to really enjoy spatial audio.
I've been looking for some way of recording Ozo sound since I got my Nokia 8 over a year ago. Up until now I've had to record video as well using the camera app, then extract the audio in Audacity.
I had written to Nokia back in September 2018 and had this reply:
Hi Mark,
OZO Audio function on the Nokia 8 is only for native camera video recording function and not open to 3rd party applications. Please contact mobile phone division for any further questions and support.
Regards,
OZO Sales
I'd also written to the author of the Hi-Q app to see if he could get Ozo audio working, but he couldn't. The audio recorded by other apps had odd audio distortion present as if some algorithm was at play distorting everything.
I'll do some testing later!
You said you could configure the microphones. For the Nokia 8 it might be useful to use the bottom mic and the one on the screen side then you can leave the phone placed on a surface and still watch the recording.
Can you explain what you've done... I can let the Hi-Q app developer know!
Thanks,
Mark.
Liftedcorn said:
It's stock Nokia camera ??*
Click to expand...
Click to collapse
Yes my phone stock Nokia camera app
With further tests on my Nokia 8 I can see the microphone by the screen doesn't seem to influence any of the recordings. You can rub it or occlude it and the stereo field doesn't shift. If you rub the mic near the flash or near the USB socket you hear mono noise (equal in left and right) added to the recording. If you occlude either of these you get mono recordings and signal is equally split between left and right. If you occlude both mics everything goes very quiet and muffled. If sound reaches both mics then it successfully puts the recording in the stereo field. As rubbing sounds are noisy in one mic but probably not heard in the other the Ozo algorithm probably sends that equally to left and right channels as it can't tell where it is coming from. There is no audio distortion heard on recording music coming from a room TV. With my Hi-Q app, rubbing either of the same mics generates noise purely in the left or right channel. And that app still suffers from some very strange audio processing where music in the room seems to get signal processed away.
In short, this is the app we've all been waiting for!
Thanks for your detailed feedback. Where is the "screen side" microphone located ? Based on the notes that came with the app "forced surround", shouldn't it also be used by the app like in the surround mode of the videos produced by the stock camera app ?
I videod a piano concert the other day and while the surround sound sounded better than the "front" option I was a bit annoyed by the "shifting" in the sound, probably due to the OZO software interpreting the sound sent by the mics.
The third mic is to the side of the ear piece, in the glass cutout line (on the Nokia 8).
Are you a professional, musician, sound engineer, or someone who needs to measure and monitor sound levels in your environment? Look no further than Sound Meter, the audio measurement and monitoring app for Android wear smartwatches.
With Sound Meter, you can easily and accurately measure sound levels on-the-go without the need for a separate sound measurement device. The app offers a range of features and functionality to help you get the most out of your sound measurement and monitoring experience.
Get a complete lowdown on the decibel levels in your surroundings with Sound Meter! It shows you the current, max, and average sound levels in real-time, giving you a spidey-sense for the noises around you. You can easily pause and resume your sound measurements at any time using the pause and close buttons. Keep track of your sound data and restart your session whenever you're ready, all with just a few taps.
In addition, Sound Meter includes an amplitude visualizer, which allows you to see the sound wave in real-time. The visualizer provides a clear and easy-to-understand representation of the sound levels, making it easier for you to monitor and manage the sound levels in your environment.
Sound Meter is designed to be user-friendly and intuitive, with a clean and simple interface that makes it easy to use even for those without a background in sound engineering. Plus, with support for a wide range of Android wear smartwatches, you can use Sound Meter on your preferred device.
So why wait? Download Sound Meter today and start measuring and monitoring sound levels like a pro.
Mod edit: DL link removed
Note:- Microphones in most devices are aligned to human voice and the maximum values are limited by the hardware. Very loud sounds (~90 dB and more) may not be recognized.
@Arunsudharsan
Greetings. I have closed your thread which is in vilation of XDA's Rules for Paid Apps and Themes, with emphasis on the following excerpt:
Spoiler
1) You must provide a free theme/app for all members. Your Thread must focus on this free theme/app. You may only mention and link to the paid theme/app.
2)The theme/app must remain free. No limited access, no registration required.
If/when you wish to provide a free version to our members, then please PM me and I'll be happy to open your thread.
Thank you for your cooperation, and have a pleasant day.
-Regards: Badger50