yashsingh1/xdaforums huggingface dataset:
[Nexus S Android Development] kong:
I still don't get the idea of this "low latency" thing. I suppose any audio player would play the song from a "buffer", which is used to hold the data processed by CPU and the "latency" would come from the time CPU used to process that data (maybe plus the time to fill the buffer?)

Then no matter what size of this "buffer" is, it always contains the same data for the player to fetch and play... so I don't see how "low latency" can improve "sound quality" or improve "sonic fidelity" unless there is a degradation of data in the buffer over time, which sounds strange to me in terms of computing :confused:

If anyone could come up with some explanations I would be really appreciated.
[Nexus S Android Development] Windows X:
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.
[Nexus S Android Development] PhaedraCorruption:
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.
[Nexus S Android Development] kong:
The "ding's" sound the same to me in all four cases. The only difference is how long until it "ding" after the "tick" in each case. However, I think I have a clearer idea why "high latency" is a problem in Android. But, IMO, this should only be the case for interactive applications that needs to produce sound whenever there is a user interaction e.g. Guitar app. In this case, the high latency may confuse the user whether they're playing it in the wrong rhythm or something like that.

But it shouldn't affect the playback of music at all because the process is just reading the file, decode it, then send the result to audio output. The worst that could happen for "high latency" in music playback is there will be a little bit delay before you can actually hear the music after the data is put in the "buffer" e.g. when changing tracks.

Please correct me if I'm wrong :rolleyes:
[Nexus S Android Development] Windows X:
The actual fact of this mod is actually getting lower latency regarding audio and it's proven by google beforehand in AOSP source that Nexus S can actually get down from 20ms to 10ms latency in ICS. One of good advantages in having lower latency for audio playback is application requiring audio pre-processing like DSP sound effects and musician apps can be more responsive to audio stream as it processes audio stream in buffer at lesser size. it helps reducing threshold required giving more space for CPU to take a deep breath for multi-tasking.

Besides actual facts, some people who don't care about low latency audio and try to make claim why he doesn't want it like sound quality is placebo, data is data and streamed the same, etc. I already said this is for people who want low latency playback and won't promise anything for sound quality so if you don't need to have low latency audio, you don't have to force your way into it. But if you want to learn about low latency things, I'm more appreciated to help explaining about it.

To make this mod more believable and trustworthy, I'll remove all my own patches and leave only proved by Google in AOSP in upcoming version according to supercurio's suggestions. This should help avoiding confusion and controversy
[Nexus S Android Development] kong:
I'm just trying to understand how "low latency" works or helps improving anything in music playback.

How many people do you think would "want low latency playback" when in fact they haven't even heard of it until you started this thread?

I believe other users may have the same questions as mine so I took time to explain my thoughts and was hoping for some clarifications/corrections/explanations. But it seems my questions never got a direct answer nor an "average Joe" understandable explanation.

Sorry if I was bothering you. Now I have a feeling that I should just stop asking questions in your thread ;)
[Nexus S Android Development] :
Bookmarked! Nice study. You should check out Blink by Malcolm Gladwell. Some nice parallels in studies of taste, showing how our brains can improve the flavour of ice cream from the look of the packaging. In one famous study he referenced, hardly anyone can tell the difference between coca-cola and pepsi in a simple triangle test.

Each 2048 sample buffer gives roughly an additional 50 millisecond delay between hitting play and the sound hitting your ears (assuming the most common bitrate of 44.1kHz). Here's a little article on latency: http://www.elvenminstrel.com/recording/ptle002latency.htm

At sea level sound travels at about 1 foot per millisecond. Most people are probably aware of the delay between seeing something happen at a long distance, and hearing it a bit later. An practical experiment anyone can conduct is to go outside and hit anything solid on to the ground. Another person standing far away can confirm there is an obvious delay.

50 milliseconds may not sound like much, but in sound, it is a lot. For example, your ears can begin to pick up pitch information from sounds starting with sounds at least 50 milliseconds long. That's pretty impressive.

Windows X seems to have retracted that this mod improves audio quality. However, he did start out by saying this was an 'Audiophile' improvement, and defended this by stating that low latencies were found to improve sound quality here: http://www.cicsmemoryplayer.com/index.php?n=CPlay.ASIOLatency

... I read that and have several criticisms of it: http://xdaforums.com/showpost.php?p=25371807&postcount=21

This is from the third post. Cleaner sound means less noise, which is testable, and I intend to test it (to prove that there is no reduction in jitter). Richer harmonics can only mean the amplitude of certain harmonics is increased proportionally to the fundamental frequency, which is a form of distortion. See here: http://www.neumann-kh-line.com/neum...8B20039968C?Open&term=Harmonic Distortion

The term 'richer harmonics' has positive connotations, and is a characteristic lauded by the proponents of tube amplifiers, where their non-linear amplification 'warms' the sound, or in more scientific terms, increases the proportional amplitude of the consonant harmonics (the even numbered ones). However, this is not possible with this mod, as it is a digital amplifier, and we are talking about latencies, not signal modulation.

Anyway. I don't think Windows X intended to mislead anyone, but claims of better sound may have been a bit over-hyped and under-substantiated.
[Nexus S Android Development] Windows X:
kong, I already answered your questions and wrapped it into one post. In my defense from many unwanted guests trying to make it sounds absurd to try, I have to make my words clear that I'm making low latency audio patch not better sound for voodoophile. I apologize if that sounds offensive to you and I already said I'm more appreciated to help in explaining about low latency thing.

As for bedalus' remarks, low latency is one of the most promising measurements worth chasing in world of pro audio and computer audiophile. I don't see why it's wrong to use scientific pro audio terms that audiophiles can make some sense with. And sonic degradation suffered from lower latency is real thing because random jitter added in latency will be wider. But you have to know how latency jitter can cause problems in quantization. It's pretty deep and easiest way is just try it and decide if you want to keep it or not. I've been in this circle numerous times already in computer audiophile.

I hope to hear your test report soon as I'm also looking forward to see how it'll work in your case too. Personally, I don't see anything wrong in here trying to have lower latency for audio playback regardless of getting better sound quality or not.
[Nexus S Android Development] klinker:
Well, i try the diference without and this mod, and i can tell the music have more "balls" with the mod and on my audio setup i can give up more volume. Maybe a normal music user on cheap audio hardware can not hear the diference, but on my Dynaudio BM5A i can hear the diference in more "balls" in music and can incrase the volume a little more, before the monitors gone in clip. Specialy the low frequencies (kick, bass,..) are more "big" and "present".
[Nexus S Android Development] cpaixao:
Lets say you'll eat a pizza, you can chew each slice 100, one by one, in 30 minutes, or eat it entirely in 10 min, chewing like crazy 100 times each slice.

Question: Whats the tastier pizza?

None. You just eat the same pizza. But perhaps you'll feel more tired after eating the second one. ^_^
[Nexus S Android Development] polobunny:
For what it's worth, I don't think anyone here has a problem with reducing the latency, rather with the claims that were made of possible audio improvements while reducing the latency. ;)

I'm interested in what Bedalus can find though. While I am in no way a certified audio engineer, I have done more than a few installations of professional hardware (MOTU & M-Audio mostly) and worked with professional software (AVID) and fully understand the concept of reducing the latency in lag sensitive cases.

I do not however ever remember encountering an instance where the latency proved to cause deterioration of the sound quality using DACs.

Either way, as I said twice before, to each their own. If you can reduce the latency while keeping the overheard to a practical level (not having to use the performance governor) then I see nothing wrong with that. At worst, it'll improve the apparent responsiveness of the device.
[Nexus S Android Development] tycruickshank:
One interesting thing regarding the lower latency which could be really beneficial is audio production apps such as caustic. The main problem with android in the past is that there is quite a noticeable delay from when a software button is pressed to when the sound is heard. It would be awesome if this mod could fix that and make it more like ios where there is almost no discernible gap. I'll report back when I have a chance to try it out. I haven't read through the whole thread so sorry if somebody as already mentioned this.

---------- Post added at 12:50 PM ---------- Previous post was at 12:17 PM ----------

So I've tried Caustic with this mod and am very happy to report that there is no discernible time between the button press and the sound through the headphones which is amazing. I've been waiting for something like this to come around for a long time. Now this is on par with any ios device in regards to that. Really fantastic work =)
[Nexus S Android Development] polobunny:
I was thinking that but did not know there was any audio production app worth mentionning on mobile. Cannot lie, I don't use my phone for anything out of the ordinary. Games, web, text and calling. :p
[Nexus S Android Development] :
Here are the data from my test:

control

-3.43 signal

-78.5 noise

=75.07 difference

extreme insane

-5.37 signal

-75 noise

=69.63 difference

extreme direct

-5.37 signal

-80 noise

=74.63 difference

extreme linear

-5.37 signal

-76.5 noise

=71.13 difference

(all measurements are RMS power in dBFS.) As we can see, the mod provides no improvement in the signal to noise ratio. The control test (no mod) was actually the best (but not significant beyond any reasonable error margins).

Clearly this shows that there is no noise reduction provided by this mod. In fact, despite setting the performance governor, I experienced audio glitches with each of the three mods (but not in the control test).

Methodology

I produced a 44.1kHz 24 bit stereo lossless WMA file of a 1kHz sine wave at -6dBFS, with one channel inverted, with appropriate dithering (provided by Waves IDR, type 1, normal noise shaping). I then recorded the output into pro tools, then routed both L and R channels into a mono aux channel, making fine gain adjustments to completely cancel out the sine wave, leaving only noise. (RMS metering was provided Elemental Audio's IXL RTAS plugin.)

So, in summary (again...) longer latencies do not introduce jitter.
[Nexus S Android Development] Windows X:
What about plus_general and plus_music? For what it's really worth, plus_general is stable for common apps use and plus_music is far more stable than extreme ones. I never once said jitter will introduce more noise. Latency jitter is something you need to measure for jitter if you want to see that caused it or not and CMP already did that.

The reason high latency is bad for audio output quality is burst of electrical activity. The larger buffer is, the longer burst runs giving more interference to soundcard (and also jitter). Plus, if you use FLL (anti-jitter in Voodoo), lower latency means more frequent of signal feeding to loop making FLL more efficiently used.

Anyway, your researched has something interesting for signal value. Your signal value after patching changed 56.57% while noise remains about the same. Why did that happen?
[Nexus S Android Development] :
Jitter causes noise. Are we talking about jitter as the bitstream gets reclocked or not?

Interference is a type of noise, and measurable. Again, I didn't measure any difference. You say jitter, so I assume you mean this thing you call "latency-jitter" (it would be easier if you stopped mixed up real terms with fantasy ones), which doesn't exist.

Everybody should have anti-jitter enabled unless the system clock is more stable than the Wolfson clock, which would be hard to believe. Anyway, it doesn't matter how big or small your buffer is, bits go to the FLL one by one.

After flashing your mod my volume set itself to a higher value. Anyone who has reported better sound quality from this mod (which as far as I can tell is only psychologically possible, rather than technically possible) has simply been fooled by hearing a louder sound.
[Nexus S Android Development] Windows X:
What I'm trying to point out is latency and noise are difference things to measure. It makes no sense from you saying you want to measure about latency jitter and give me signal and noise report. Where's latency measurements? Read http://www.cicsmemoryplayer.com/index.php?n=CMP.03Jitter#PeriodicJitter in Jitter research part carefully and do some experiments like his if possible.

Judging from how you talk about FLL, you don't really know how it works at all do you? The more hz of buffer streaming feeding to loop, the more accurate loop can lock. It's also stated in http://www.cicsmemoryplayer.com/index.php?n=CPlay.ASIOLatency but as PLL which use similar concepts of locked loop.

For 'latency jitter' definition, go ask Emm labs, dCS, RME, Metric Halo and Weiss engineers whether it's fantasy word or not. There's more than what you think it has to be done to make stuff like tens of thousand bucks source worth it.

Again, there's clear evidence that lower latency can give benefit to improve locked loop features like FLL/PLL and minimize range of periodic jitter in given links. But using the word 'fooled' was a bit hypocrite as if you don't really care to learn anything new from it and offended all the people who said the opposite to you. I don't like continue talking in this manner.
[Nexus S Android Development] :
Would you explain what a FLL does please?

EDIT:

http://www.cicsmemoryplayer.com/index.php?n=CMP.03Jitter#PeriodicJitter

Good article. You want me to do an spectrum analysis? I can do that. But this article doesn't mention 'latency-jitter'.

http://www.cicsmemoryplayer.com/index.php?n=CPlay.ASIOLatency

Yeah, I remember this link from the last time you posted it. You didn't respond to any of my numerous criticisms of it. Here they are: http://xdaforums.com/showpost.php?p=25371807&postcount=21
[Nexus S Android Development] Windows X:
Your criticism doesn't sound like you know what you're talking with so I left it unanswered. The relation between those two links is ASIO Latency talking about periodic jitter and that link explains how periodic jitter can ruin up digital domain.

for FLL, I suggest you doing some google search and coursework first and I'll help explaining anything you stumble upon if I can.
[Nexus S Android Development] wildestpixel:
I'm with Bedalus here particulalrly as a statistician, R & D fellow and coder.

Editing a source file to decrease a value is something I do on a basic level with SystemUI.apk.

Supercurio has got the whole out of this device, don't effing patronise him, Bedalus or in turn myself thankyou.
[Nexus S Android Development] kong:
That's what my low-fidelity ears observed as well.

What happened to this?

Why am I quoting myself here?

Déjà vu ;)
[Nexus S Android Development] Windows X:
I read all that and already explained to you guys for what really happened and matter in that case. If you have any further questions about fidelity in computer audio, you should visit given links and check other sections as well to study more from cics' research.

Personally, I don't think there's anything wrong asking him to learn about something available in Google himself after providing all resources and knowledge I think I could share. If that's too offensive, I think labeling people who think differently as 'being fooled' is far worse. So I may went up little bit too emotionally but you know that really hurted me for all of you lot did without contributing anything for the better in this thread. Or maybe low latency audio I/O is pointless for ROM cooker? I don't really know now.
[Nexus S Android Development] wildestpixel:
Todays four letter word folks isn't swearing. Its more like utility.
[Nexus S Android Development] Windows X:
Well then, explain why and what effing patronise stand for in this thread? Just when thread become something more constructive.....sigh. I'll settle with bedalus through PM then. And sorry for kong that I can't give you average job understandable answer. I've tried it already though.
[Nexus S Android Development] Chuckd610:
.....and the "beat" goes on...no pun intended
[Nexus S Android Development] :
Via PM I finally understand that Windows X is talking about something known as periodic jitter, which is usually a result of electo-magnetic interference from the power supply (not applicable in this case since no transformer involved) or cross-talk in the clock signal from some other signal.

Windows X believes that smaller buffers can reduce periodic jitter. After a great deal of thought, I suppose it is possible (but I think rather unlikely) that a small buffer being filled frequently, as opposed to a large buffer being filled infrequently, could have some impact on the clock due to cross-talk. However, this problem must surely affect only extremely high end digital audio equipment, where the highest standards of noise level must be maintained. A further caveat must be that rather than changing buffer behaviour, a far simpler solution would be to redesign the PCB and/or ICs to eliminate the potential for cross-talk.

With that said, I wanted to provide some objective measure, so I have run various spectrum analyses on the audio I produced yesterday.

Here's the pure 1kHz sine I created:

Here's the control test (no mod) 20Hz-20kHz

View attachment 1042910

Here's the extreme direct mod 20Hz-20kHz

Here's the extreme linear mod 20Hz-20kHz

Here's the extreme insane mod 20Hz-20kHz

I wanted to zoom in on where I saw some interesting behaviour, so...

Here's the control test (no mod) again but 1kHz-20Khz

Here's the extreme direct mod again but 1kHz-20Khz

Here's the extreme linear mod again but 1kHz-20Khz

Here's the extreme insane mod again but 1kHz-20Khz

What we can see here is that the nexus s has a high noise floor (not audiophile quality) and was unable to faithfully reproduce a sine wave at -6dBFS without distortion (hence the odd and even harmonics - again, not audiophile quality). This is not surprising, since no one was claiming that the nexus s is an audiophile device.

What I was looking for was some sign of a periodic jitter. There were some very small spikes just above the noise floor in a few places, that appeared to be uncorrelated to the sine wave, and candidates for periodic jitter, however, these same spikes appear at the same frequencies for all three mods and the control test, so must be attributed to some other interference (most likely cause is mains hum, judging by the frequencies).

There are two possibilities,

1) The mod has no effect on cross talk or there is no cross talk to affect

2) The mod does affect cross talk, but it is buried too far under the noise floor to be measurable (or audible)
[Nexus S Android Development] Windows X:
Thank you, bedalus. The information is very informative. The graphs of low-latency look like they're having lower noise floor a bit except insane that looks like being broken. If scale of db isn't changed at all, lower noise floor should be something rewarding from low-latency thing. Cross-talk sounds interesting put but I'm more interested about lowered noise-floor from given graphs.

For highend equipments, testing latency using self-made music server between 0.7ms and 50ms is like day and night in $100k system and every normal people can tell apart for the difference. It sounds clear enough to make anyone notice there's something different without looking after giving them 15 mins of audition. While the test on Nexus S is probably less than 2-5% of difference I can hear in $100k system. If I'm not into audiophile thing, I surely won't notice it. I still remember my early days when I can't tell apart between stock cheap mini to mini cable and little better ones.
[Nexus S Android Development] :
The noise floor is higher in the control test because the volume was higher. Check again the signal to noise figures I gave yesterday. The best noise level was in fact the control test without the mod.
[Nexus S Android Development] Windows X:
I see. Did you test patched file with platform? If so, please test again without using platform file so you can compare only modded file (which volume should remain the same).