DX50/90 Firmware Modification - Fidelity Edition LITE by Windows X

[WindowsX]

Since @Lurker0 demanded for my explanation and I don't want to derail the discussion in main DX90 topic any further, I decided to start a new topic here so people who're interested in modding firmware can discuss without disturbing ordinary users.
 
To make it simpler to understand, I decided to build a firmware without adding or removing any single line of tweak this time so you'll see the changes clearly. I'll use only existing configuration in original DX90 firmware and only main boot configuration from kernel image and build configuration from main ROM files that'll be optimized. Let's see how far we can go. I'll start with DX90 first.
 
I'll start modding from line to line below with some brief explanation. I'll explain with assumptions that you already understand each configuration so please do your homework by studying what each one does by yourself because explaining every one of them will take forever to finish this post.
 
 
 
First, I'll start with main boot configuration file from kernel image. Here we go!
 

Spoiler: Boot configuration

write /proc/cpu/alignment 4 >> 0
 
Since mango is only running process and not likely to be killed off, setting to 0 make it does nothing which isn't anything about the sound but I prefer it this way personally.
 
write /proc/sys/kernel/sched_latency_ns 10000000 >> 1500000
write /proc/sys/kernel/sched_wakeup_granularity_ns 2000000 >> 30000
 
I normally set sched_latency_ns to 1000000 and leave sched_min_granularity_ns with 100000. According to the rule, I can't set the latter so let's leave it at that for MangoPlayer being only process.
 
write /proc/sys/kernel/sched_compat_yield 1 >> 0
 
Setting to 0 will make process running in completely fair scheduler having each CPU running at 50% rather than 99% in one core. That should help handling I/O operations better and reduce weird stabilty issues.
 
write /proc/sys/kernel/randomize_va_space 2 >> 0
 
This will disable ASLR meaning no more randomized virtual address. Since this is DAP with only mango running, disabling it for static mapping is better for performance-wise, no matter how small it is.
 
write /proc/sys/kernel/kptr_restrict 2 >> 0
 
This will disable kernel pointer's restriction. Disabling it makes kernel pointers work with less instructions without going through restriction check.
 
write /proc/sys/kernel/dmesg_restrict 1 >> 0
 
This will allow non-admin level user to read messages. Might be useful in future but not really matter.
 
write /proc/sys/vm/mmap_min_addr 32768 >> 4096
 
I tuned this value down for mapping address block at 4096 instead of every 32768 for less overhead. I'm bufferless fan and hate to see large overhead.
 
write /proc/sys/kernel/sched_rt_runtime_us 950000 >> -1
write /proc/sys/kernel/sched_rt_period_us 1000000 >> 10000
 
write /dev/cpuctl/cpu.shares 1024
write /dev/cpuctl/cpu.rt_runtime_us 950000 >> -1
write /dev/cpuctl/cpu.rt_period_us 1000000 >> 10000
 
write /dev/cpuctl/apps/cpu.shares 1024
write /dev/cpuctl/apps/cpu.rt_runtime_us 800000 >> -1
write /dev/cpuctl/apps/cpu.rt_period_us 1000000 >> 10000
 
write /dev/cpuctl/apps/bg_non_interactive/cpu.shares 52
write /dev/cpuctl/apps/bg_non_interactive/cpu.rt_runtime_us 700000 >> -1
write /dev/cpuctl/apps/bg_non_interactive/cpu.rt_period_us 1000000 >> 10000
 
Runtime tasks will work without reserving percentage for lower priority. I also reduced period size to smallest possible at 10000. This makes kernel resource utilization becoming more linear for better audio performance.
 
write /proc/sys/vm/min_free_order_shift 4 >> 1
 
Since DX90 doesn't run with large order of chunks like server scale, setting to 1 will improve allocation times.
 
write /proc/sys/vm/dirty_expire_centisecs 200 >> 6000
write /proc/sys/vm/dirty_background_ratio  5 >> 30
 
Increase dirty expiration to 1 minute and increase background ratio for longer idle time and less battery consumption.
 
service console /system/bin/sh
class core
console
disabled
user shell >> root
 

Changing user to root will allow shell command to run as root. init.d script works better with root access.
 
service vold /system/bin/vold
class core
socket vold stream 0660 root mount
ioprio be 2 >> ioprio rt 2
 
Improving volume storage service performance by changing itd I/O priority to real-time scheduiling category with order 2 (after MangoPlayer/usbhifi).
 
service mango /system/bin/MangoPlayer
class main
user root
group audio graphics
ioprio rt 4 >> ioprio rt 0
 
Increase priority of MangoPlayer to highest order 0. That should be better.
 
service usbd /system/bin/usbhifi
class main
user root
group audio graphics
ioprio rt 4 >> ioprio rt 1
 
Increase priority of MangoPlayer to order 1 (after MangoPlayer).

 
Now let's see how build configuration file from ROM image looks like.

 

Spoiler: Build configuration

ro.build.display.id=rk3026-eng 4.2.2 JDQ39 eng.liuwenlong.20140123.133948 test-keys >> DX90 - Fidelity Edition LITE by Windows X
 
Since I won't add any lines at all, spare me one line for making note to know it's my tuned ROM here.
 
dalvik.vm.heapstartsize=5m >> 8m
dalvik.vm.heapgrowthlimit=48m >> 32m
dalvik.vm.heapsize=256m
dalvik.vm.heaptargetutilization=0.75
dalvik.vm.heapminfree=512k >> 256k
dalvik.vm.heapmaxfree=2m >> 1m
 
Tuned Dalvik heap size for better allocation balancing in DX90. Some what affect sonic performance.
 
persist.usb.debug=0 >> 1
 
Enable USB debugging. I usually enable it on my devices so I'll do with DX90 as well.
 
dalvik.vm.dexopt-flags=m=y >> v=n,o=v,u=n,m=n
 
Optimize dalvik flags for no verification/optimization applied. Pure solid performance is way to go.

 
Though it's not even half of what I usually did but looks like I've done more than I imagined before starting this project. Right now I'm kinda busy so I'll dig up DX50 firmware some other time. There's still a lot more to be done with recent 2.2.0 firmware such as new parameters and init.d scripts, etc. but for now it should be enough to prove that you can still do more with 2.2.0 firmware.
 
I don't know how much of my explanation will reach you guys, I'm not really good at it. I hope you'll consider your listening experience with my modified ROM as means to evaluate the changes I made. And no matter how senseless my tweaks may seem to be, it's my opinion and mine alone. It's my decision to configure it this way and please respect my opinion and my work being shared here.
 
http://www.mediafire.com/download/wy8pvbfhbbr4351

 

[Lurker0]

OK, you've dropped the lines I asked about, but I'd like to ask about the lines mentioned here: why do you ever need to touch Dalvik parameters for DX90? DX90 has no JVM at all, even as binary files!
 
I will not ask other questions nor provide any comments for a while: will do step by step.

 

[WindowsX]

Dalvik JVM for android apps are removed but not for VM of OS. DX90 still have VM and that changes affect it.

 

[Lurker0]

Reading my answers, you may take offence once again, but, before you do, please consider that I'm in programming since 1979, and participated in many different projects, including OS development, and even hardware development

I'm just trying to share my experience.
 
Quote:

Dalvik JVM for android apps are removed but not for VM of OS. DX90 still have VM and that changes affect it.

I asked you for Dalvik only: you set some parameters (dalvik.vm.*) that are used by Dalvik only, and those your changes are totally useless. You silently confirmed that in your previous build many settings you changed were useless as well, now you just can't say "yes, I did it because I don't know what I'm doing!".
 
The next question: do you know how exactly the option "persist.usb.debug=0" in DX90?

Spoiler: The answer

If persist.usb.debug=1, the first, after the boot, connection to a PC will start adb instead of "Mass storage" mode. Changing USB settings in DX90 after the boot effectively overwrites this option.

To start adb in DX90, there is another way. You may find it in my firmware builds.

Edit: I realized I might be wrong with above! It might be related to "persist.sys.usb.config=mass_storage,adb". Then, persist.usb.debug has no real use on DX90.

I'll continue to not to waste more time later.
 
Very high priority for a user interactive application is always bad idea, in any OS. This is because background threads of the application would slow down or even prevent system tasks that serve user interaction (keyboard, mouse, touchscreen), device I/O etc.
 
Instead, real-time priority with a high enough level is good for a background task that serve time sensitive device events.
 
Having this basic knowledge, and also knowing that usbhifi serves USB Audio DAC mode by reading sound data from USB port and sending it to the DAC, it would be logical to make usbhifi priority higher than Mango, or keep it equal, but you made it exactly opposite. Meaning, your configuration may perform worse in USB DAC mode, but never it can be better.
 
In embedded devices like DX90 with flash memory used for storage, "disk" writes are usually cached and delayed. This is done to consume limited slash write cycles not too soon. When a user tries to turn DX90 off, Mango saves its settings (including the current track and time position) to the "disk", and then calls the system for shutdown. With the highest possible priority, there is a chance that Mango may turn the power off before all the buffers are actually written. This may lead to settings loss, or even to file system corruption. Frankly, it happens with DX90 time to time, but very rare. I even recommend not to turn DX90 off immediatelly after "Rescan Library", when a vast amount of data is waiting for delayed writes. Your modification increases the chance of such misbehaviour, and makes nothing better in return.
 
/proc/sys/vm/mmap_min_addr parameter has no relations to the words you used to explain your change. You can start understanding it e.g. here.
 
I think I said enough to let you userstand that you need to learn and investigate a lot before publishing your work to end customers. I see nothing really useful in your modifications. Instead, I see some unpleasant or even dangerous changes. If you didn't take it yet - I'm failed!

 

[WindowsX]

  Reading my answers, you may take offence once again, but, before you do, please consider that I'm in programming since 1979, and participated in many different projects, including OS development, and even hardware development 

 I'm just trying to share my experience.

 
Your past experience is irrelevant here. Moving on.
 

 
I asked you for Dalvik only: you set some parameters (dalvik.vm.*) that are used by Dalvik only, and those your changes are totally useless. You silently confirmed that in your previous build many settings you changed were useless as well, now you just can't say "yes, I did it because I don't know what I'm doing!".

 
It's true that libdvm.so was removed in recent 2.2.0 release. However, it used to be there in past version and I tried changing that to extremely low parameters before and it didn't boot up. The only mistake I made here is I didn't verify all my merged tweaks with 2.2.0 firmware. You should ask iBasso why they put these useless tweaks over there in the first place not me. I only replaced what was there with things I did before. I'm busy and don't have that much free time to recheck everything just to explain you. I think I'm already generous enough to waste my time explaining things to you knowing you don't actually try to learn but pin the blame for the sake of winning the argument instead. You never admit in your wrongdoing at all, not even once.
 

  The next question: do you know how exactly the option "persist.usb.debug=0" in DX90?

Spoiler: The answer

If persist.usb.debug=1, the first, after the boot, connection to a PC will start adb instead of "Mass storage" mode. Changing USB settings in DX90 after the boot effectively overwrites this option.

To start adb in DX90, there is another way. You may find it in my firmware builds.

Edit: I realized I might be wrong with above! It might be related to "persist.sys.usb.config=mass_storage,adb". Then, persist.usb.debug has no real use on DX90.

 
If you're wrong, just admit it. Adding might is no different from telling I don't really know. I already explained above why I changed to 1 and you should respect my opinion not forcing everything you think onto me. I told you I changed it just cuz I usually do that. Even it does nothing at all, I'd do that too from habits.
 

  I'll continue to not to waste more time later.
 
Very high priority for a user interactive application is always bad idea, in any OS. This is because background threads of the application would slow down or even prevent system tasks that serve user interaction (keyboard, mouse, touchscreen), device I/O etc.
 
Instead, real-time priority with a high enough level is good for a background task that serve time sensitive device events.
 
Having this basic knowledge, and also knowing that usbhifi serves USB Audio DAC mode by reading sound data from USB port and sending it to the DAC, it would be logical to make usbhifi priority higher than Mango, or keep it equal, but you made it exactly opposite. Meaning, your configuration may perform worse in USB DAC mode, but never it can be better.
 
In embedded devices like DX90 with flash memory used for storage, "disk" writes are usually cached and delayed. This is done to consume limited slash write cycles not too soon. When a user tries to turn DX90 off, Mango saves its settings (including the current track and time position) to the "disk", and then calls the system for shutdown. With the highest possible priority, there is a chance that Mango may turn the power off before all the buffers are actually written. This may lead to settings loss, or even to file system corruption. Frankly, it happens with DX90 time to time, but very rare. I even recommend not to turn DX90 off immediatelly after "Rescan Library", when a vast amount of data is waiting for delayed writes. Your modification increases the chance of such misbehaviour, and makes nothing better in return.

 
While it sounds some what convincing, your explanation lacks the observation from real practices. Default configuration has storage instability issues and getting better in current firmware. By changing vold's io priority to realtime category, it actually improved I/O performance and reduce issues from happening. Many of my DX90 customers said so (with other tweaks I added in full firmware not this ones). Even with troublesome firmware like 2.1.x is working mostly fine with my tweaks. Also, DX90 has only touchscreen and play control buttons. Default priority of MangoPlayer and USBHiFi are both set to rt 4 meaning they're both classified at realtime level by iBasso already. I only changed its order. I set priority order to 0 (MangoPlayer), 1 (USBHiFi), and 2 (Vold) to avoid chance of corruption. It did improve over all system performance if you actually bother to test my firmware. Also, MangoPlayer handles audio render and audio playback as well, putting USBHiFi above MangoPlayer can lead to playback stuttering due to USB hogging resource causing starvation in MangoPlayer.
 
I learnt this experience from a few USB Audio Interface from developing computer transport since last decade. I have my own reason for doing that and you have yours. You may have your disagreement but it doesn't mean you're absolutely right in all cases.
 

  /proc/sys/vm/mmap_min_addr parameter has no relations to the words you used to explain your change. You can start understanding it e.g. here.
 
I think I said enough to let you userstand that you need to learn and investigate a lot before publishing your work to end customers. I see nothing really useful in your modifications. Instead, I see some unpleasant or even dangerous changes. If you didn't take it yet - I'm failed!

 
Your given link was the first thing I found when I was researching it and to be frank, you seem to be lacking in this department to not fully grasp the understanding behind it. It could be dangerous if I do this on large scale enterprise server but this is DX90 having 512MB RAM with only one 4MB size image process playing single audio file. Reducing this allows user to map low portions of virtual memory, meaning I can lower the overhead cache of VM tuning better. You should study on cases why it should be reduced as well. I'll give some links for example here.
 
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/216398
http://archlinuxarm.org/forum/viewtopic.php?f=55&t=1865&start=100
 
And it was fine after long tests since early firmware mods. I hope my explanation against your claims are clear enough. I understand your intolerance against placebo effects of tweaks that does nothing but is that all you can say? Why don't you focus on tweaks that could help the firmware improvements like sched_latency_ns, sched_rt_runtime_us, sched_compat_yield, or sh as root for example?
 
I think I've said enough to let you understand that you need to learn and investigate with real practices not just thinking it in your head from your past experience alone. Have you even tried my firmware mod for real once? You're kind of people who turn 3 of 10 things you don't like into 10 things that go wrong leaving 7 things behind. Right now you find 3-4 things you don't like in my tweaks, you turned it into I made useless tweaks and everything is sounding like crap without even touching it. I'm not surprised why doc2008 and probably many others would find it hard to talk things through with you.

 

[Lurker0]

  You should ask iBasso why they put these useless tweaks over there in the first place not me.

There is a huge difference between iBasso (who built firmware from Android sources, and haven't deleted some redundant settings and binary files) and you (who pretend to optimize the result of iBasso work).
 
Good luck

 

 

[WindowsX]

  There is a huge difference between iBasso (who built firmware from Android sources, and haven't deleted some redundant settings and binary files) and you (who pretend to optimize the result of iBasso work).
 
Good luck

 

 
Again, only try to pin the blame and I already admit it was my mistake that I didn't recheck the redundant changes I made after new firmware comes out. btw, I happen to build a few Android ROM from sources as well like this ones.
 
http://forum.xda-developers.com/xperia-z/development/rom-cm11-0-fidelity-edition-t2298976
 
Since you don't seem to be interested in discussing about my ideas of firmware improvements here, I think this should be the end of discussion between us.
 
Good luck

 

[WindowsX]

After finishing discussion with Lurker, I decided to complete my firmware with some additional lines to make it works as I expected. I run listening tests for few hrs and I think this has better sonic performance than first release.
 
http://www.mediafire.com/download/wy8pvbfhbbr4351

 

[vaggbaba]

You are great man. thank you. I admire your work. If you had time to improve Ibasso dx 50 such as you do on dx90 It would be wonderful. And I believe for the above discussions that we must discuss for the improvements. I am 100% with you.

 

[WindowsX]

I no longer maintains free iBasso firmwares after getting bashed by Lurker0 and his fans. It's a shame but I don't appreciate in offering free stuff and get trashed. I will only maintain paid services from now on, not that I can get money but I don't have to handle with ungrateful bunches.
 
Regards,
Keetakawee