Welcome to XDA

Search to go directly to your device's forum

Register an account

Unlock full posting privileges

Ask a question

No registration required
Post Reply

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

OP Windows X

3rd May 2012, 06:38 PM   |  #91  
supercurio's Avatar
Senior Recognized Developer
Flag Chambéry
Thanks Meter: 5,072
 
3,529 posts
Join Date:Joined: May 2010
Donate to Me
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/referen...udioTrack.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
Last edited by supercurio; 3rd May 2012 at 06:43 PM.
The Following 6 Users Say Thank You to supercurio For This Useful Post: [ View ]
3rd May 2012, 07:30 PM   |  #92  
Maximilian Mary's Avatar
Senior Member
Flag Wisconsin
Thanks Meter: 289
 
886 posts
Join Date:Joined: Jan 2011
Donate to Me
More
Quote:
Originally Posted by 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/referen...udioTrack.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

The Following 3 Users Say Thank You to Maximilian Mary For This Useful Post: [ View ]
3rd May 2012, 07:52 PM   |  #93  
OP Senior Member
Thanks Meter: 1,301
 
739 posts
Join Date:Joined: Sep 2006
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.
Last edited by Windows X; 3rd May 2012 at 07:57 PM.
3rd May 2012, 09:31 PM   |  #94  
glennkaonang's Avatar
Senior Member
Flag Surabaya
Thanks Meter: 194
 
509 posts
Join Date:Joined: Feb 2012
More
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.

Sent from my Nexus S using xda premium
3rd May 2012, 09:48 PM   |  #95  
OP Senior Member
Thanks Meter: 1,301
 
739 posts
Join Date:Joined: Sep 2006
Quote:
Originally Posted by 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.

Sent from my Nexus S using xda premium

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.
Last edited by Windows X; 3rd May 2012 at 09:57 PM.
3rd May 2012, 10:01 PM   |  #96  
polobunny's Avatar
Senior Member
Flag Montreal
Thanks Meter: 2,480
 
6,180 posts
Join Date:Joined: Oct 2011
More
Quote:
Originally Posted by 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.

Sent from my Nexus S using xda premium

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.
The Following User Says Thank You to polobunny For This Useful Post: [ View ]
3rd May 2012, 10:17 PM   |  #97  
OP Senior Member
Thanks Meter: 1,301
 
739 posts
Join Date:Joined: Sep 2006
Quote:
Originally Posted by 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.

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.
Last edited by Windows X; 3rd May 2012 at 10:21 PM.
3rd May 2012, 10:49 PM   |  #98  
polobunny's Avatar
Senior Member
Flag Montreal
Thanks Meter: 2,480
 
6,180 posts
Join Date:Joined: Oct 2011
More
Quote:
Originally Posted by 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.

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.
The Following User Says Thank You to polobunny For This Useful Post: [ View ]
bedalus
3rd May 2012, 11:23 PM   |  #99  
Guest
Thanks Meter: 0
 
n/a posts
Just a note to say some testing will be underway as soon as I get back.
The Following 3 Users Say Thank You to For This Useful Post: [ View ]
3rd May 2012, 11:58 PM   |  #100  
OP Senior Member
Thanks Meter: 1,301
 
739 posts
Join Date:Joined: Sep 2006
https://github.com/peteralfonso/plat...467cd8f48cb4a3

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/plat...246a1c785a6d3c

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/plat.../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/plat...a5756264620234

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.
Last edited by Windows X; 4th May 2012 at 12:10 AM.

Post Reply Subscribe to Thread

Tags
audiophile, head-fi, libaudio, mod, nexus s
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes