[ghosthost]

@jkbuha... after extensive testing with 2.5 and the earlier beta of 2.6 you'd posted for another member, my earlier problem with the freezing, crashing and rebooting does seem to have been the result of my unit being one of the ones with the lower-grade VCOs rather than an issue with the startup scripts not completing. At this point with the new 2.6 release installed, the player seems very zippy indeed and stable, so far. I still have an app or two to test that was giving it headaches earlier... I will, of course, report back with any issues. Many thanks for all the hard work you've put into this project.

In layman's terms (software I understand, but the hardware terminology is a little vexing), what is it about the earlier settings do you suppose affected my unit so negatively?

- S.

 

[jkbuha]

@jkbuha... after extensive testing with 2.5 and the earlier beta of 2.6 you'd posted for another member, my earlier problem with the freezing, crashing and rebooting does seem to have been the result of my unit being one of the ones with the lower-grade VCOs rather than an issue with the startup scripts not completing. At this point with the new 2.6 release installed, the player seems very zippy indeed and stable, so far. I still have an app or two to test that was giving it headaches earlier... I will, of course, report back with any issues. Many thanks for all the hard work you've put into this project.

In layman's terms (software I understand, but the hardware terminology is a little vexing), what is it about the earlier settings do you suppose affected my unit so negatively?

- S.

Put simply, the CPU and DDR ram in some devices could not take high clock speeds, and the previous versions of the kernel did not implement a mechanism to drop the speed in case of math errors.

I've now implemented some checksum logic to reduce speeds if any math errors are encountered (think of it as an anti-lock system) but the algorithm might not downclock in time for Android to throw an issue, in which case the kernel reboots. If you get any issues, PM me and I'll give you a new build with lower clock speeds.

 

[west0ne]

Dear Head-Fi community

After some extensive work over the last few weeks I am very happy to announce the latest release - Version 2.6 of the @FiiO X5iii custom kernel. This release contains by far the largest amount of new features and changes, and elevates the player usability and user experience in a class above its own. Indeed comparing the original factory versions with this custom kernel gives the X5 a new premium feel in terms of smoothness and execution.

Changelog

Version 2.6
New: UKSM instead of KSM (much faster)
New: ZRAM (more RAM)
New: fsync_disable (much, much faster)
New: ROW I/O scheduler for SD cards (much faster)
New: LZ4 Compression instead of LZO (faster, more compression)
New: zsmalloc implementation instead of xsmalloc
New: zcache enabling (faster)
New: ARM RSEM implementation (faster)
New: frandom generator instead of random (much, much faster)
New: MSG pop-up notification daemon
Fix: Lowered voltage for some FiiO players with lower-grade VCOs
Fix: Corrected git file dependencies
Fix: Disabled system animation by default

Previous Versions

Version 2.5
New: Increased max clock speed to 1752MHz (faster)
New: BFQ I/O scheduler (faster)
New: Westwood TCP/IP congestion protocol (much faster)
New: InteractiveX governor (much, much, much faster)
Fix: Stability checks to voltage
Fix: iX handling changes

Version 2.4
New: Maple I/O Scheduler (faster)
New: init.d full support (much, much faster)
New: init.d scripts (thanks prispewnic @ 4PDA)

Version 2.3
New: Zen I/O scheduler (much faster)

Version 2.2
Fix: Changes to scheduler priorities during screen off (faster)

Version 2.1
New: Additional GPU and DDR overclocking (much, much faster)

Version 1.5
New: Update to Linaro gcc 4.9.4 (significantly much faster)

Version 1.4
New: SIO I/O scheduler (faster)
New: VR I/O scheduler (faster)

Version 1.3
New: CPU clock to 1704MHz (much, much faster)

Version 1.2
New: Additional voltage optimisation and DDR overclocking

Version 1.1
New: GPIO optimisation and documentation
New: CPU clock to 1518MHz (faster)

Version 1.0
Initial system release and branch-off from FiiO GPL code

Installation instructions:

1) Windows and/or first-time users
If you already have TWRP or a previous version of my kernel, go to step 2.

a) If you don't yet have TWRP and/or any previous version of my kernel yet, download the Windows-based loader here and unzip to a folder
https://androidfilehost.com/?fid=1395089523397899882
(note: you need to have the FiiO USB Windows drivers correctly installed)
b) Run the AndroidTool.exe program and connect the FiiO via USB.
c) Put the player in bootloader mode (just as if you were going to upgrade the player the traditional FiiO way with the Windows-based loader), by pressing power+pause+back.
d) If all goes well you should see the green light with 'Found One Loader Device'. Make sure 'boot' and 'recovery_twrp' are selected and press Run. Once done, click the 'Advanced Function' tab and click Reset Device. You should have the new kernel and TWRP installed!

2) TWRP users

a) Download the latest version of the kernel (with new optimisation scripts) here:
https://www.androidfilehost.com/?fid=1395089523397899873 and push to sdcard
b) Reboot to TWRP recovery
c) Install -> FiiO-X5iii-jkbuha-V2.6-TWRP.zip
d) Wipe kernel and dalvik cache
e) Reboot
f) IMPORTANT: leave running for 1-2h for new scripts to do their magic
g) Reboot
h) Enjoy

3) Hints and Tips
After the first couple of reboots, you should immediately see an increase in usability and responsiveness due to the new kernel features and scripts in play.

If you're using Fidelizer (as I am) then you'll need to delete *.flac and *.pdf from your /system/media folder before you install my kernel.

Note that this version pushes the hardware to its maximum capabilities, so if you experience any random reboots, it's likely that your specific player may need slightly lower tuning settings. PM me and I'll send you a custom build!

Thanks and Rants

Again, massive thanks to prispewnic's product suggestions. His extensive knowledge of requirements and scripting have been the source behind all these new great features. Thanks also to the great community of users here on this forum, your support and feedback so far has been incredible.

Thanks also to @FiiO for releasing the first GPL of the source code back in June. If it weren’t for you we wouldn’t have this modded kernel. Also - gentle reminder - could you kindly release the source code for firmware version 1.2.2?

Coming up next
Version 3 is next, this will be quite an ambitious project, so expect even better CPU governors, I/O schedulers and faster internet on this player in the coming weeks

As always, any queries, comments etc - please shout.

Moderators - could someone pin this to the first post of this topic? It's a real shame that new users have to trudge through 1000 odd pages before they get to this...

Is Root needed for the scripts to run and for the features they bring to work.

 

[jkbuha]

Is Root needed for the scripts to run and for the features they bring to work.

Not in this case. The scripts run in init.d stage, which is executed by the system daemon on boot.
That said, I feel it always helps to have root to give you better visibility and control on what's going on.

 

[ghosthost]

Put simply, the CPU and DDR ram in some devices could not take high clock speeds, and the previous versions of the kernel did not implement a mechanism to drop the speed in case of math errors.

I've now implemented some checksum logic to reduce speeds if any math errors are encountered (think of it as an anti-lock system) but the algorithm might not downclock in time for Android to throw an issue, in which case the kernel reboots. If you get any issues, PM me and I'll give you a new build with lower clock speeds.

Gotcha. So... some variation in quality control in one/some of the chips, then, I take it. The biggest problems with 2.5 seemed to have occurred with the Castbox podcast app. I'm assuming that given the complex nature of that app's UI and the background tasks it's performing (artwork downloading, subscription downloading, etc.) that it was driving *something* way too hard... frequent lockups and app crashes rather than Android itself crapping out. Intriguing...

 

[Brooko]

Neutron works really well so far with X5iii and new 2.6 Kernel.

 

[TiborG]

Put simply, the CPU and DDR ram in some devices could not take high clock speeds, and the previous versions of the kernel did not implement a mechanism to drop the speed in case of math errors.

I've now implemented some checksum logic to reduce speeds if any math errors are encountered (think of it as an anti-lock system) but the algorithm might not downclock in time for Android to throw an issue, in which case the kernel reboots. If you get any issues, PM me and I'll give you a new build with lower clock speeds.

Congratulations, very nice progress. Interestingly, Wifi while playing over Foobar2000 on a minidlna server is nice to have a connection in Linux. After scanning the server when playing shuffle, playing for the next pause breaks up to a par in a milisecond - 5 meters from the router. 1 meter from router without pause - as well as from SD card (uncompressed PCM 44.1 kHz). Overall lightning response to such anemic hardware - my deep bow, comparable to my Samsung Galaxy S6 (root and lightweight to bones). If you are able to make some progress in the stability and performance of the Wifi connection in Version 3.0, TIDAL will be happy to use it. Spotify is smooth for long time.
Do you think the Wifi performance is reduced in FiiO firmware due to possible audio component interference?

UAPP is a bit more leery, but the screenshot says clearly.

 

[nekromantik]

Neutron works really well so far with X5iii and new 2.6 Kernel.

Are you not getting the random issue where neutron closes itself after a track finishes?
Used to happen all the time even before custom kernel and ROM.
Still happens on latest Fidilzier.

 

[Brooko]

Not on my unit. Played about 4 hours last night. Not a single hitch

 

[Ghost Of Lundy]

Are you not getting the random issue where neutron closes itself after a track finishes?
Used to happen all the time even before custom kernel and ROM.
Still happens on latest Fidilzier.

I’m getting that with 2.6 even after clearing
Cache and Davike cache amd lettong it pretty much run all day. and And I’m using regular Fiio1.2.2. I’ve reinstalled nuetron. Crossing my fingers

 

[jkbuha]

I’m getting that with 2.6 even after clearing
Cache and Davike cache amd lettong it pretty much run all day. and And I’m using regular Fiio1.2.2. I’ve reinstalled nuetron. Crossing my fingers

I use Neutron a lot and it's never closed since the LMK (low memory killer) parameters have been optimised. Then again, with only 1GB of RAM you're going to be pretty tight on what programs you can run concurrently.

What I'd suggest - if you have root - is to load up kernel adiutor and experiment with the LMK settings tab. You can choose between conservative and aggressive and see what works best.

 

[jkbuha]

Congratulations, very nice progress. Interestingly, Wifi while playing over Foobar2000 on a minidlna server is nice to have a connection in Linux. After scanning the server when playing shuffle, playing for the next pause breaks up to a par in a milisecond - 5 meters from the router. 1 meter from router without pause - as well as from SD card (uncompressed PCM 44.1 kHz). Overall lightning response to such anemic hardware - my deep bow, comparable to my Samsung Galaxy S6 (root and lightweight to bones). If you are able to make some progress in the stability and performance of the Wifi connection in Version 3.0, TIDAL will be happy to use it. Spotify is smooth for long time.
Do you think the Wifi performance is reduced in FiiO firmware due to possible audio component interference?

UAPP is a bit more leery, but the screenshot says clearly.

That's an interesting point. The wifi chipset in the X5iii is not the best (and that's putting it kindly) but I suspect the major issue is how the antenna cable is run through the sides of the player, possibly due to component interference but (I strongly suspect) also due to the short run given the outer perimeter of the player . Also 5GHz is not available, so - yeah, Wifi performance is reduced.

As of V2.5 the kernel now supports westwood tcp congestion instead of reno, which will improve things considerably, but we're still restricted to the limitations of the hardware.

Very happy to hear you're getting lightning UI response, especially with Tidal/UAPP.

 

[TiborG]

That's an interesting point. The wifi chipset in the X5iii is not the best (and that's putting it kindly) but I suspect the major issue is how the antenna cable is run through the sides of the player, possibly due to component interference but (I strongly suspect) also due to the short run given the outer perimeter of the player . Also 5GHz is not available, so - yeah, Wifi performance is reduced.

As of V2.5 the kernel now supports westwood tcp congestion instead of reno, which will improve things considerably, but we're still restricted to the limitations of the hardware.

Very happy to hear you're getting lightning UI response, especially with Tidal/UAPP.

First I was suspected of Wifi antenna (I have already repaired badly connected contacts in 2 notebooks) but within 1 meter of the router is a very good connection. I did not have any TIDAL functionality, it was just an estimate about how to play in my weak WiFi network without audio compression.

 

[nekromantik]

@jkbuha if first boot after flashing kernal you had to restart before scripts finished.
how can you re run them?

 

[jkbuha]

Don't worry, they run automatically by the system init.d daemon every boot.