[MOD][TWEAK][03/05] Nexus S: Fidelity 2.0 - Ultimate Low latency audio playback

***WARNING!!! THIS MOD IS FOR PEOPLE WHO LOVE HAVING ULTIMATE AUDIO PLAYBACK SYSTEM ONLY (LOW LATENCY, LINEAR BIT-STREAM, AUDIO PERFORMANCE AT ITS BEST). IT'S NOT AIMED FOR LONG BATTERY LIFE OR FAST/SMOOTH PHONE AND MAY NOT WORK RIGHT ON YOUR PHONE. I'M NOT PROMISING ANYTHING ABOUT SOUND QUALITY IMPROVEMENTS AND DON'T WANT TO DEBATE ABOUT IT***



After spending months in github looking in Voodoo Sound code and gotta admit I have no idea how it could get any better. Finally, i found something interesting to improve sonic quality that can make us audiophiles smile for higher fidelity. Time to say goodbye to Android life with just Voodoo + cool music player alone.

Six months ago...after ICS firstly released, Google patched audiostream buffer in Nexus S' audio library increasing buffer size and latency after fixing latency delay in 4.0.2 and so on. For normal people's perspectives, it should be a good move as we get stable audio stream, more battery friendly and no more delay issue.

However, some purist computer audiophiles may not agree and have strong motto about 'low latency'. Some Windows players like JPLAY and XXHighEnd went far enough to feed single byte buffer feeding audio card. Not that lower is always better as I prefer minimum hardware buffer size over something extraordinary.

Back to the topic, so I messed around with Nexus S' audio library wondering why no one ever tried that before. As this is first attempt, I'll try to make things as extreme as possible according to what it's capable off.

As there're a lot of misconceptions about latency and jitter stuff so I'm not gonna explain how any those stuff will do about audio performance. Better let your ears decide it as it wouldn't hurt to try. Let's see what this brings to you now.



Features:

Features come in build packages below. Make sure to read all of them as you need to carefully pick out the best for your need. I added my own platform optimizations script in version 2.0 and improved audio library according to new platform performance. I also added Galaxy S (I9000) device support and will try to make more devices like Galaxy Tab and Galaxy Nexus in future. Also keep in mind that there's no best sounding build without sacrificing system's stability.



Builds:

platform: This is innovation of the year for all Android.....no for all Linux-based audio systems and technically work on any Android devices too. Specialized platform for lowest possible I/O latency and CPU utilization having audio thread optimized to its finest having real-time I/O with priority at highest level, Voodoo Sound and Color configuration for purist un-altered sound, kernel resource scheduling optimized to highend DAW level, CPU+I/O+kernel optimized for low latency, audio effects being disabled completely and plus_music patched audio library. It'll have to remove all existing scripts in init.d as most of them can screw this ones up. It'll give you best environment to run even more extreme patches in 2.0 at more battery-friendly setup.

plus_general: Designed for battery-friendly build at 10ms latency playback. You can use this on any ROM, kernels, tweaks you like. General build uses original ICS frame buffer size before modifications and trimmed down buffer size to be the same size as ICS frame for direct frame buffer transfer. I recommend getting plus_general if you don't want to get sloppy second like other builds.

plus_music: Also designed for battery-friendly like general but use even smaller frame buffer size to only 128 at 8 frames for 5ms latency playback at stock environment. It's designed for only music playback alone so you may get some playback problems aside from music playback. To make this stable, I increased number of frames in buffer pool from 4 to 8 according to ALSA's ideal specifications. It works fine on most governors but 100MHz or deep idle may cause some problems. This still works fine on most apps except you try having music played in background on intensive apps.

plus_google: This is alternative design for ideal 5ms latency playback based on plus_general design. Frame buffer size being reduce from original ICS frame buffer size (448) to 256 at 4 frames. The reason I picked ALSA's specifications for music is most ALSA drivers configured for low-latency use that but doesn't mean it's generally better than this ones. I personally prefer lower frames rather than lower frame size at same pool size.

extreme_direct: Designed for those who want to go extreme with lowest possible hw/sw buffer design having buffer pool exactly the same size as output buffer. It's plus_music having number of frames in buffer pool trimmed down from 8 to only 2. Yes.....2 for smallest possible frame buffer pool. You need to install optimized platform environment to keep this stable or run it on high performance setup.

extreme_linear: Designed for those who want to go extreme with smallest possible frame buffer size design. It has only 32 frame buffer size (1/32 of normal buffer size) and have 8 frames in buffer pool. I doubt you can run this at stable level without optimized platform. It has highest battery consumption of all but doesn't mean it works the best. Direct design provides fuller dynamics with more depth while this ones gives you richer ambient with smooth sound.

extreme_insane: Designed for those who want to go extreme with everything smallest possible. It has 32 frame buffer size (1/32 of normal buffer size) and only 2 frames in buffer pool making buffer pool 1/4 of other extreme patches. I said insane because it's beyond what this phone is capable of technically. Even in specialized platform on performance govenor may not music played till the end without single spike. You can only try making it stable with steve.garon's filesync off kernel after patching specialized platform. The reason I didn't include his kernel in because it causes occasional reboots and currupt data partition due to disabled filesync running insane task.



Downloads

nexus_s_fidelity_platform

nexus_s_fidelity_plus_general

nexus_s_fidelity_plus_music

nexus_s_fidelity_plus_google

nexus_s_fidelity_extreme_direct

nexus_s_fidelity_extreme_linear

nexus_s_fidelity_extreme_insane

nexus_s_fidelity_restore



Changelog

[03/05/12] Version 2.0
-Added audio thread priority optimizations to highest level
-Added audio I/O priority optimizations to highest real-time level
-Added CPU optimizations for low latency playback
-Added Galaxy S (I9000) device support
-Added kernel resource scheduling optimizations
-Added I/O optimizations for low latency playback
-Changed Voodoo Sound headphone gain to 0db (2db has too high hiss on low impedance phone)
-Fixed clear old scripts in init.d that didn't work last time
-Removed libaudioeffect_jni.so as it increase more load and latency
-Removed DSPManager as it can't be disabled and keep showing error during music playback
-Removed wildestpixel tweaks
-Tweaked audio library improvements
|-plus_music uses library from version 1.0 for Alsa's ideal specifications
|-plus_google added as alternative ideal 5ms design based on Google's Android code
|-extreme_direct now has 1/2 frame buffer size comparing to 1.1 version
|-extreme_linear now has 1/8 frames comparing to 1.1 version
|-extreme_insane added with everything smallest from other extreme patches
|-restore now also remove installed optimizations and restore libaudioeffect_jni.so

[28/04/12] Version 1.1
-Added plus_general for all-around use at 10ms latency playback
-Added plus_music for music focused use at 5ms latency playback
-Added extreme_direct and extreme_linear for non-compromise builds
-Added restore for people who want to use current AOSP build

[27/04/12] Version 1.0
-Initial release with kernel/tweaks for 8x1/8 frame buffer optimized for 5ms latency playback



If you experiences any playback problems, try changing minimum frequency or use suited governors, I/O, CPU settings in NSTools. I'm quite satisfied with battery-life in version 2.0 and never have issue after finalizing version 2.0.

I'm almost done. Only DSPManager left to deal with now. Hope I won't end up having to delete it as it bricked my ROM several times already.

2.0
-Added CPU optimizations for low latency playback
-Added disabling DSPManager on startup as it'll keep showing error
-Added extreme_general to see how implementing 5ms in plus_general design works
-Added I/O optimizations for low latency playback
-Disabled audioeffects from messing up audio thread introducing more load and latency
-Fixed clear old scripts in init.d that didn't work last time
-Fixed Voodoo Sound headphone gain to 0db (2db has too much hiss on low impedance phone)
-Removed Voodoo Color calibration
-Removed wildestpixel tweaks
-plus_music mode uses library from version 1.0 for Alsa's ideal specifications
-extreme_direct now has 1/2 frame buffer size comparing to 1.1 version
-extreme_linear now has 1/8 frames comparing to 1.1 version

I'm really sleepy and tired now so if you don't see files being uploaded in next 2hrs, come back tomorrow

Just, to be clear: reducing buffer size won't improve sound quality in any way.
Sad to see yet another mod using big fat keywords to fool people with placebo.

About latency it seems you have no idea how AudioTrack and others API are working, how developers set buffer sizes.
You can start here:
http://developer.android.com/reference/android/media/AudioTrack.html

My recommendation, as usual: some intellectual honesty by publishing measurements, for both sound quality and latency.

Note: I'm not saying its useless to try to improve things. Just that using buzzwords to trigger placebo and mislead people is wrong.

2 requirements:

• Strict methodology
• Measurements

Guess it's better to remove DSPManager.apk then. What I planned yesterday are all done now but the more I look into, the more interesting things I wanna tryout. Now platform can be adjusted for any kernel to run extreme patches with uber-super-cool-godly-awesome tweaks I've just made and it's pretty much battery friendly too. I'm really glad that I can use new extreme_direct on _thalamus's latest voodoo kernel without using performance governor.

I'll leave the phone on with newly implemented kernel tweaks on stock-like kernel tonight and see if it'll keep singing fine tomorrow. If it goes well, I might try even more extreme patches before releasing tomorrow. Stay tuned!

Windows X said:

Some good sites from quick search regarding latency

http://www.rossbencina.com/code/dave-sparks-on-android-audio-latency-at-google-io-2011 <--- Google talking about latency problems. ICS in Galaxy Nexus seems to improve to 20ms. Still miles behind iOS API lower latency from good low CPU usage and power consumption. I hope Google will implement PulseAudio in newer Android build.

http://www.synthtopia.com/content/2...t-possible-to-play-music-on-an-android-phone/ <--- Some good sites explaining with data and examples. Try listenig audio clip from 0ms latency to over 300ms and ask yourself if they're all sound the same.

Hmmm. I just know iOS having 5.4ms latency playback. It's such shame that iPad/iPhone didn't use good Wolfson DACs. Sonic quality from lower latency is having more responsive audio output, more continuity of bit-stream, more linear of the sound closer to ideal from quantization.

Btw, it seems supercurio noted something interesting in https://docs.google.com/document/d/1uHMkJwXFqVT3Di2JwILUnNCsqa8styA8T3y4RtTpcv8/edit?pli=1

"Cpu frequency transition latency: 100000 ns"

This is called "/proc/sys/kernel/sched_latency_ns" in Android and I changed it to 100000ns for supported kernel. I doubt he ever looked into my work before giving comments.

Click to expand...

Click to collapse

I've been following this thread for the last little while and it seems that there is quite a bit of controversy regarding the effects of this mod.

The obvious answer here would be to just "try it" and see if you hear a difference, but the human mind simply does not work this way.

I did a small controlled experiment awhile back regarding the effects that the mind has on what we hear, the results simply proved that we hear what we want to hear. (If you're interested, you can find the experiment here)

The way I see it, once a certain point is reached, hearing a difference does not mean there actually is a genuine difference in sound quality, in order to prove beyond a reasonable doubt that an improvement has been made, I believe it is necessary to introduce completely unobjective tools and measuring devices.

The best bet for anyone to finally put a conclusion once and for all on this mod is simply to do a couple of measurements in the form of electronically recorded sine sweeps with a control (baseline stock measurement) to compare to.

I don't know nearly enough about how phone audio codecs work to add anything of value to the discussion, however I'm certain that with measurements presented, a unanimous decision can be made regarding the true effects.