yashsingh1/xdaforums huggingface dataset:
[Nexus S Android Development] Windows X:
Version 1.1 is released. I also added extreme builds for those who want to follow their philosophy to the best without saving battery-life.

Versions:

plus_general: Designed for battery-friendly build at 10ms playback latency. You can use this on any ROM, kernels, tweaks you like. General version 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 versions.

plus_music: Also designed for battery-friendly like general but use even smaller frame buffer size to only 256 for 5ms playback latency. It's designed for only music playback alone so you may get some playback problems aside from music playback alone. To make this stable, I increased number of frames in buffer pool from 4 to 16 in order to make it works fine on most governors and deep idle. This still works fine on most apps except you try some apps having music played in background.

extreme_direct: Designed for those who want to go extreme with lowest possible hw/sw buffer design. It's plus_music having number of frames in buffer pool trimmed down from 16 to only 2. Yes.....2 for smallest possible frame buffer pool while keeping direct frame buffer transfer. You need performance governor to keep this stable. From my tests with Air Kernel, it seems you can keep deep idle for stable music playback.

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 64 frames in buffer pool. It doesn't use direct frame buffer transfer like above but feed small chunk in out buffer optimized for 5ms playback latency. You also need performance governor to keep this stable. It has highest battery consumption of all but doesn't mean it works the best.

If you experiences any playback problems, try changing more powerful governors, I/O, CPU settings in NSTools. I'll keep first release for those who want to try out optimal of original design. I'm quite satisfied with battery-life in plus_music and never have issue with any plus builds.
[Nexus S Android Development] mamba720027:
Ok I turn on my phone after this and my house pose is shakeing with the sound :D
[Nexus S Android Development] qu3becker:
While I find this to be a fine project. I would like to see a file that revert changes so that we don't need to use a backup if we find this patch has no use for us afterward.

Thank you for your great work.
[Nexus S Android Development] Windows X:
Thank you. Now I added restore file.
[Nexus S Android Development] d1xt1r:
I just flashed directly the extreme linear version, and from what I played and heard there's definitely a difference (in good way) between the standard nexus s sound and the modded version. The music sounds much more live now. Thank you Windows X.

Best regards,

Dex
[Nexus S Android Development] Jerry69:
Can I flash this over SlimICS?
[Nexus S Android Development] maped:
great job bro :thumbup: ... I'm interested to know if your mod has a great influence on consumption of the battery :rolleyes:

Inviato dal mio Nexus S con Tapatalk 2
[Nexus S Android Development] Windows X:
Hope you like it. How's the others?

Yes. You can. plus_general should work on all cases but the rest may not depending on ROM/kernel build. I tried flashing 5ms ones on ported xperia s but no luck.

Generally, lower latency will consume more battery. plus_general consumes less of all.
[Nexus S Android Development] jjjameson:
My device : i9023 with CyberGR-MOD v.11 & AirKernel

Headphones : Brainwavz M2 (http://www.yourbrainwavz.com/m2.htm)

Player : GoneMad Music Player (It has great soundstage. Better then PowerAmp and PlayerPro)

Well i tried all tweaks. I got best sound from extreme_linear.

I turned off deep idle and go with smartassV2. No issues. No freezes, gliches.

Anyways my headphones Frequency range is 20 ~ 20000Hz and Distortion: <= 0.3% @ 94dB. So its enough to have fun with sound..

There is a lot of change. I heard more detail, bass is same. Trebs went higher. Louder sound.

In the end, i love this mod. If you use it with a good pair of headphones you gonna love it too..!

And the battery goes the same..

Thank you for this mod again..! Its great..!
[Nexus S Android Development] migueldbr:
so how does this perform when compared to voodoo sound?
[Nexus S Android Development] b1337:
You could flash yourself and see....kinda the point...
[Nexus S Android Development] migueldbr:
well thank you, hadn't thought about doing that-_-

or maybe i just wanted to know the opinion of people who have tested it before i start flashing anything that could cause performance issues on my phone...
[Nexus S Android Development] AnthonyG92:
There are already a few opinions posted, but you yourself would be the best judge :) as no one has mentioned much about comparing it with voodoo could you give it ago and give us a bit of feedback? :)
[Nexus S Android Development] kong:
It's basically Voodoo Sound running on smaller buffer and shorter latency.
[Nexus S Android Development] leets4uc3:
I am and pixel Bb 0.3L. Lazy and sio 100/800. With extreme linear. Only got to test it for 10 minutes. Drained about 10%. Didn't really test it very well so far. Didnt notice a huge difference than voodoo with my crappy $15 skull candies. There was 2-3 glitches with the music in ten minutes but that was expected with my kernel set up.

I am going back to the plus music and will be testing that tonight on my bike home. Linear is to Much of a drain for me.
[Nexus S Android Development] akshayf:
Could someone please clarify that is this mod supposed to be used in conjunction with the voodoo sound or should I set the default values in the voodoo app??
[Nexus S Android Development] Windows X:
Already explained in few posts back. You can use this with Voodoo for direct_dac sound at lower latency. Anyway, I'll be removing old builds soon and replace with 1.2 builds so grab them if you want to keep old tweaks.
[Nexus S Android Development] Windows X:
Good news for all extreme fans. I can finally optimize rom environment to run all extremists at minimalist. Now you can even get improved extreme_linear running at 100MHz!!! The key is to reduce bottomneck of I/O latency to compromise with CPU workload. It should be available within next 24hrs. :D
[Nexus S Android Development] Windows X:
Right now I'm testing 5ms ones that should work on most ROMs in http://xdaforums.com/showpost.php?p=25451470&postcount=1036. I think I can finalize and upload tomorrow as version 2.0.

New plus_music should is actually original build from first version following ALSA ideal specs 128x8 for audiophile computer audio. It works fine on stock-like environment (200-1000MHz ondemand). If you use deep idle or 100MHz, things may go wrong and I suggest running conservative 100-1000MHz instead for more battery saving (Not 100% safe for 100MHz though). ondemand didn't work well on gradually changing CPU speed so it'll just hit high and low unlike conservative.
[Nexus S Android Development] Oodie:
1.I'm on Slim ICS & what should I flash ? there are lots of zips ( nexus_s_fidelity_plus.zip /nexus_s_fidelity_plus_general.zip )

2. After flashing do i need to change any settings with dsp manager or voodoo sound app ?

Edit : No need for an answer for the 1 st question :D just saw the changelog :D
[Nexus S Android Development] Windows X:
Flash this ones http://xdaforums.com/showpost.php?p=25451470&postcount=1036

Flash plus_music or plus_general for time being. If you don't mind kernel being changed, flash first file having Air Kernel 4.0 and wildestpixel tweaks.
[Nexus S Android Development] Oodie:
Tried with slim & air kernel 4 bigmem , default kernel settings .

I can tell that there is a significant improvement in music & sounds as my poor headphone can tell .

Thanks for the mod buddy .

Sent from my Crespo
[Nexus S Android Development] qetuol:
in NEUTRON player there is an option in advanced settings to change software and/or hardware latency. Are they the same things you are talking about here regarding to latency?
[Nexus S Android Development] Windows X:
Glad you like it. I'm almost done on adjusting low latency platform. It seems 100MHz is too risky for extreme sets (I got black screen and stuck at boot screen a few times) so I'll leave it at 200MHz.

As Neutron doesn't have source released so I don't know what API it uses to handle playback and all that stuff. But from what I see from audio library, all devices have stuff like frame size and count for buffer and MediaPlayer API (commonly used in Android system) will get buffer settings from audio library. Saves me time and trouble for tweaking buffer in Android's framework :D
[Nexus S Android Development] klinker:
Hi Windows X

I'm a music maniak (dj and producer) and i want to try your mod.

I used rom Rascream sandwich with Trinity T11 kernel, governor performance with 200-1096mhz and Ubermusic app for play my music.

Wich mod you recommend me for best audio performance and stability

Tnx
[Nexus S Android Development] d1xt1r:
Very much. I haven't tried them yet, i will wait for your next releases. Keep up the good work. :)

Dex
[Nexus S Android Development] Chuckd610:
Has anyone tried all the variations in the OP? Just wondering which one has the best sound. BTW, I have a Crappy.....It appears from the files I looked at, it should work for me.
[Nexus S Android Development] roshga:
waiting for version 2.0 :D
[Nexus S Android Development] Windows X:
First ones (I mean plus alone without _blablabla) is still the best for 5ms with stability wise. That would be plus_music in version 2.0 also. If you want to keep your own kernel/config, extract files in lib/hw and push it yourself.

Right now I'm having trouble about system restarts and ROM being bricked from one of extreme library in 2.0 environment. I suspect DSPManager being the culprit as it'll always hook on audio thread without disable function. I'm thinking of counter-measure now.

I tried all and I can say you'll have to try all again in 2.0 so just stick with what I said first for now.
[Nexus S Android Development] Windows X:
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 :D
[Nexus S Android Development] d1xt1r:
Great news! :)
[Nexus S Android Development] Windows X:
Back. Still couldn't get DSPManager killing work. Tried am force-stop com.bel.android.dspmanager but no luck. It worked form adb shell but not in init.d script. Also tried adding sleep beforehand but no luck still.

If I can't find a way to stop it, I may end up removing it on installation. Here's the script I added in.

sleep 5;

am force-stop com.bel.android.dspmanager;

Anyone know how to solve this? It reported as "segmentation fault" from script launch. Weird, huh?
[Nexus S Android Development] jjjameson:
i dont use DSP manager :) you can push it to me, i can try
[Nexus S Android Development] Windows X:
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! ;)
[Nexus S Android Development] roshga:
using the 1.1 plus version with trinity for a couple of days now, the difference is not that big but noticeable.

version 2 seems to fix lots of minor issues that I had, for example in my car stereo couldn't leave voodoo value on 2amp, changed it to 0 and the sound was clear again,

cant wait until version 2 is out.

@Windows X - thank you for the hard work. really appreciated
[Nexus S Android Development] Windows X:
Version 2.0 is done now. Right now I'm adding other WM8994 devices support like Galaxy S and Tab. The improvements will make your jaw dropped for sure and worked fine on any kernel (and I'm talking about extreme ones ;))
[Nexus S Android Development] mkoch820:
Can't wait :)
[Nexus S Android Development] Chuckd610:
Jaw dropping sound! That's what I'm talkin 'bout....
[Nexus S Android Development] DaXmax:
I will support you in Galaxy S Development... ;)
[Nexus S Android Development] Windows X:
Finished patching all Galaxy S audio library files. Seems to work as good as Nexus S here (I have both phones and Tab is coming). It seems my hdd is running out and deleting crespo+galaxysmtd folder wont cut any space in VMWare. Looks like I'll have to redo everything from scratch again for Galaxy Tab.
[Nexus S Android Development] HeavenlyWinds:
Love it, makes a huge difference. I also love the gamma settings , makes black pitch Black and Blue pop.
[Nexus S Android Development] Windows X:
Damn...internet always getting disconnected all night thanks to poor TP-Link router. Gotta download files again after waking up (70% done now I guess). I also fixed some tweaks last night during tests with plus and default ones. Now all should work fine though some may have little pause during first minute boot up.

With some demands on Galaxy Nexus, I'll try to look into Tuna code and see what can be done. Don't blame me if things don't work right on Galaxy Nexus because I don't own one to test.
[Nexus S Android Development] apatal:
Looking forward to trying out version 2.0 on my phone's rascream_thalamus combo. :D
[Nexus S Android Development] Windows X:
Version 2.0 released. Information and downloads can be found in first page. I also added Galaxy S device support and other devices will come in 2.x branch.

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
[Nexus S Android Development] Shadow-Nexus:
Did you remove the voodoo color thing?
[Nexus S Android Development] Windows X:
As some said they love it, I decided to keep it. It won't work on kernel without Voodoo Color though.
[Nexus S Android Development] roshga:
I don't know which one to pick!!!

Guess I'll just have to try them all...
[Nexus S Android Development] Chuckd610:
Which version will work best on a Captivate?
[Nexus S Android Development] Windows X:
Good news and bad news about upcoming 2.1 for you guys.

Good news: 2.1 will be out tomorrow with Galaxy Tab P1000 support. It seems other tab models use proprietary audio library with no source file so there Tab 7 based models will be only one supported for time being. Galaxy Nexus support is already in consideration but I don't have ones to test right now though.

Bad news: Most customized kernel may not have it but some kernels like _thalamus supports configurable kernel resource scheduler which can greatly improve linearity of bit-stream from optimizing this. If you configure granularity down to minimum value, CPU will have more load combined with bufferless I/O making frequency sky rocked to over 400MHz most of the time. I'm trying to find solution if I can moderate its performance without adding too much latency.

For best version, that really depends on user preferences. Some prefer plus over extreme, some prefer google over music, some prefer direct over linear, etc.
[Nexus S Android Development] Chuckd610:
I guess I'll be flashing all of them......lol
[Nexus S Android Development] Chuckd610:
WindowsX you are on something really big with this tweak. Outstanding work!
[Nexus S Android Development] Blackcrx:
just to clarify, i can flash whichever build i want or do i need to flash the platform first and than the general, music, etc.. build?
[Nexus S Android Development] Windows X:
Thank you. It may not really solve latency issue in Android platform but at least audio playback get this resolved for better.

There's no dependency between those to so you can flash whatever you like first :D
[Nexus S Android Development] supercurio:
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
[Nexus S Android Development] Windows X:
Just to be clear that I also know about fundamentals for pro audio playback and checked things through before starting this project. That's why I made tons of builds for people to test around. One followed original Google design in early ICS build, ones followed ALSA's specifications, ones going extreme beyond hardware and API for normal environment.

You guys should also be aware that default 2048 buffer size is what Google suggested to be stable for all tests and usage but doesn't mean hardware can't go lower than 2048 as they specified 896 (448*2) before and it worked just fine in older ICS more than 6 months ago. What's wrong to put old code back or use different design from Alsa's audio interface drivers? Let alone extreme that I clearly said it's not something for general use to specifications.
[Nexus S Android Development] glennkaonang:
Not that I doubt you, but what supercurio said might be a good idea.

An analysis or measurements would be great.

Some people would prefer to see "numbers" to words.

Once again this is just a thought, not a critique nor a mock.
[Nexus S Android Development] Windows X:
If I claim Nexus S can go all the way down to stable 1-5ms latency without having distortion or dropout at all and would be logical sense to push this in AOSP, that would be interesting to prove it with analysis and measurements. But what I did here for real was bringing up old stable code back. The rest are more like gimmick or try like seeing how high this 3GHz CPU can go up to.
[Nexus S Android Development] polobunny:
You know what's fun with audiophile snake oil? Somehow they haven't found a way to prove it, yet, after all this time of making claims. Same reason you can pay thousand of dollars for a 5 foot cable.

Not complaining, to each their own. Ima stay out of this topic. :)
[Nexus S Android Development] Windows X:
It's snake-oil when you pile up your money onto it and I don't see why grabbing old code from AOSP is the same reason as buying $xk cables. I'm also 100% confidence that you didn't even try any single file before posting, did you? Even Voodoo Sound doesn't have every feature must checked and I never butt in saying which shouldn't be used. Let alone extreme stuff out of this OK? I'm not stupid enough to not realize it can't work properly as stable framework.
[Nexus S Android Development] polobunny:
This is exactly the reason why I'm staying out of this kind of thread. It quickly escalates in a childish battle with absolutely no way to end it because there's no scientific testing that has been done.

It's equally as funny as making an amp that goes to "11", simply because 11 is higher than 10, thus should be louder.

And no, I did not test any of these files, I do not use my Nexus S for listening to music. I am not targetting you in any personal way, I am not an audio engineer, audiophile from a higher sphere or super hero in disguise.

I am simply stating that until actual change to certain numerical values are pinpointed as having an improving factor on audio quality, it's hard to believe something is not snake oil.

Blind tests are your friend, here.

Also as I said, to each their own. :)
[Nexus S Android Development] :
Just a note to say some testing will be underway as soon as I get back.
[Nexus S Android Development] Windows X:
https://github.com/peteralfonso/pla...mmit/f4527973111826c537c5b5507d467cd8f48cb4a3

Here he changed output buffer period size from 1024 to 448 because in early implementation didn't work fine at 1024.

https://github.com/peteralfonso/pla...mmit/a1fee1161f403d8fba66a7d76d246a1c785a6d3c

Now he changed back from 448 to 1024 again saying it's not necessary anymore and higher buffer size will save up more battery.

What we know here? Reducing period size to 40-50% still works fine without trouble except consuming little more battery and smaller period means smaller buffer size leading to lower latency too.

Same goes for Galaxy Nexus. Let me explain here

https://github.com/peteralfonso/platform_device_samsung_maguro/blob/ics/device.mk

Galaxy Nexus uses audio library code from tuna base. so let's see tuna code changes that has comment about latency value.

https://github.com/peteralfonso/pla...mmit/a4a40e0b7574584643a20df358a5756264620234

This ones is pretty obvious. The goal is to have lower latency and optimizing audio performance to perform well at lower latency is the most important of all. Not to mention that early period size of Nexus S having 448 which is less than 50% of 24x44 = 1056 in Galaxy Nexus's low latency mode right now. Specs in Galaxy Nexus should be like 2-3 times better but Nexus S can handle latency at half fine until increase buffer patch? Sound quality regarding latency size is subjective and I already said that I'm not giving any promise to sound quality improvements though some may perceive noticeable changes in what they hear. I want to have lower latency playback and and I feel snappier having it. :)