I’ll do some experimenting in a little bit see if turning off the wifi helps (bluetooth already off), I have turned it off before when recording a mix because I’d seen it suggested but never checked the latency.
But I have a feeling this will make no difference as its not the processing time where its slowing down, but i’ll check back in a bit and let you know.
While messing around on the S4 last night I found that turning tha WiFi off did nothing to help. Also 8.4ms is the lowest I can have while on 48100, Don’t get me wrong even on 8.4ms I have a very responsive controller but… But it’s still pissing me off that I know a 3rd party USB soundcard will out put in 4.2ms 
Also the fact we have (padi) both have mac books and the S4 yet your time is so low
Peace out guys!
I really think you’re searching for something that may not even be necessary. 8.4ms is still incredibly small. You should be fine when playing music especially considering that human error (for pushing buttons) is more than 100 times that amount. (This is for your thumb to a stopwatch 
)
keep in mind.
the s4’s usb cable is also carrying high rez midi data along with the audio signal.
your audiobox has the luxury of only carrying audio.
I have suggested that this be the case in a earlier post.
Also anything over 10ms is noticeable to me when using the jogwheel, but what is bothering me is that I know there are people out there running pretty much the exact same set up but getting a lot lower latency.
Also if I lower the sample rate the output time go’s up
I can get the lowest latency on my system running 96000 with a larger buffer than with 44100 with the smallest buffer. To me it makes no sense, I was hoping someone could explain whats happening.
[ame=“Digital audio - Wikipedia”]Digital audio - Wikipedia, the free encyclopedia@@AMEPARAM@@/wiki/File:Text_document_with_red_question_mark.svg" class=“image”><img alt=“Text document with red question mark.svg” src=“http://upload.wikimedia.org/wikipedia/commons/thumb/a/a4/Text_document_with_red_question_mark.svg/40px-Text_document_with_red_question_mark.svg.png”@@AMEPARAM@@commons/thumb/a/a4/Text_document_with_red_question_mark.svg/40px-Text_document_with_red_question_mark.svg.png[/ame]
The reason increasing the sample rate reduces the latency is simple math.
You’ve got 48000 noises a second or 98000 noises a second.
Now, your buffer is 128 - traktor stores 128 noises and plays them all.
SO traktor empties it’s buffer at a rate of 48000 or 98000 giving…
37.5 (48000) or 76.5~(98000) new buffers each second.
Meaning…
When I press play traktor stores 128 noises in memory BEFORE any sound is sent.
When I say scratch, traktor adds this new sound to the end of the buffer and it gets played but not until after the other 128 noises have played.
The time it takes to get to this sound (the latency) is decided by the sample rate as I showed above.
Did that make any sense kids? Or do I get another talking fruit?
I understand that but mine do’s the opposite of normal!
If I LOWER the sample rate the output time go’s UP!
absolutely. let me try to formulate it in different words.
The buffer in Traktor determines the number of samples that are stored. so a buffer size of 128 means that 128 samples are stored.
now, if you work at 44.1kHz, there are 44,100 samples per second. Let’s say we start with a full buffer. If the computer cannot process audio (suppose it’s because it’s busy doing other stuff), the audio can continue to play without interruption until the buffer is emptied.
how long is the buffer in units of time? well, we have 128 samples / (44,100 samples / s) ~ 0.0029s = 2.9ms. Thus, at a sample rate of 44.1kHz, the music can continue to play for just under three milliseconds until we get a dropout.
now suppose we double the sample rate to 88.2kHz. if we keep the buffer size at 128, you can go through similar math to find that the music can continue to play for just under 1.5ms until we get a dropout.
thus, when we increase the sample rate without increasing the buffer, the buffer becomes less generous and the chance of dropouts or glitches increases. to illustrate this: in the first case (with 44.1kHz), if the computer is “busy” for 2ms and cannot replenish the buffer, we don’t get a dropout. in the second case (with 88.2kHz), if the computer is busy for 2ms and cannot replenish the buffer, we DO get a dropout.
Add to this that it is about twice as computationally intense to do audio processing at 88.2kHz than at 44.1kHz. So even if you doubled the buffer to 256 samples, the chance of dropouts is still higher in the 88.2kHz case than in the 44.1kHz case.
of course, all of this is abstracting from a bunch of things but i think this illustrates the core issue. OP, you’re lying to yourself, nothing’s for free 
It is simple,
Buffer size divided by sample rate = latency
eg:
256 samples / 96000 Hz = 0.0026 seconds or 2.6 ms
256 samples / 44100 Hz = 0.0058 seconds or 5.8 ms
The bottom line is that 96KHz has significant advantage in audio quality when using Traktor and it provides much lower latency. The only disadvantage is that it has a higher CPU cost, but if you have a modern CPU and your laptop is optimised well this shouldn’t make any difference in use.
As a demonstration of how using 44,100Hz loses information:
If your source track is 44,100Hz and you play it at +4, in one second you will have:
44,100 x 1.04 = 45,864 samples
If you then play that out at 44,100Hz you lose 1,764 samples every second.
If you play it a high sample rate you lose nothing.
When you apply EQ and effects and key lock there is a huge amount of extra information generated.
Most people are completely missing the point, I would expect the higher sample rate i.e. 96000Hz(more info) to take longer to process then 48000Hz (less info). But i’m getting it the other way around.
48000Hz with a buffer of 128 = 8.4ms
96000Hz with a buffer of 128 = 4.2ms
Please people stop trying to explain the basics and look at my numbers! It doesn’t make sense to me, for the 48000Hz to have a larger latency.
^^^ you still don’t get it. probably the reason is traktor is reporting things in a confusing way. traktor does NOT show your system’s actual latency but it shows you what are essentially buffer sizes. please re-read my post.
what you observe is a reduction in the amount of music (in units of time) that is stored in the buffer.
to give a drastic example: I install traktor on some 10 year old, super-slow computer. after 30min sweat, the installation finally goes through. i now set the buffer in the audio settings panel to 64. And WAAAAAAAAAAAAAAAAAM!!! Traktor now shows super-low latency on my lemon of a computer.
if you think this is the computer’s actual latency, you are wrong. if you think the actual latency is much higher and at current settings we’ll get nothing but glitches and drop-outs, you are right.
Your numbers are correct, that is the way it is. What is wrong is your assumption. The answers have been given to you, it is up to you if you want to understand them. 
The setting are different in the S4 version of Traktor.
You can set the sample rate & buffer, traktor then tells you the:-
Processing time & the output then adds them to give you the over all. (and its fairly accurate) also I have tested the settings on my machine to make sure its stable (so I know the latency is correct).
The 96000Hz setting with the same buffer size OUTPUTS faster then the smaller sample rate of 48000Hz with the same buffer size.
“Latency is a measure of time delay experienced in a system” from (wikipedia) I.E. how long it takes from me moving the jog-wheel for it to be processed and outputted.
Why would it make sense for the higher sample rate 96000Hz (more infor and higher cpu usage) be more responsive!
Also please explain how Padi use’s a macbook with less RAM & a S4 but has a much lower output time.
If I could get my output time down my numbers would read:-
Sample rate 48000Hz
Buffer 64
Processing: 1.3ms
Output: 2.7ms
Overall: 4.0ms
But this is what I have:
Sample rate 48000Hz
Buffer 64
Processing: 1.3ms
Output: 5.7ms
Overall: 7.0ms
OUTPUT 5.7ms when I was using Serato scratch live I had a stable latency of 5ms (my output time is more than that now without adding the processing time)
To reiterate, Why is my out put time so high?
Okay I’ll give this another bash but let’s try an analogy this time…
Say traktor is a car, the sample rate is the speed traktor is traveling at and the buffer size is the tracks length.
Traktor if traktor goes at 48000 or 98000 on the 128 track, which one is going faster?
On the padi_04 thing, I too get a different number to him. I get:
48000
64
1.3 5.7 7.0
Meaning I probably have a different Macbook to him (I have a 09 unibody 13)
The way I see it is, 96000Hz is more info to process than 48000Hz so it should take longer & I’m right it do’s take longer to process but… even though it processes 48000Hz faster it still takes longer to output (I know sample rate just sends more info, but its signal isn’t any faster traveling down the wire), So why the massive slow down in output time on what I see as the smaller task(less info).
96000Hz = More information to process
48000Hz = Less information to process
I just want someone to explain whats happening at the output stage & not the processing stage, as the processing stage acts as I would expect (the larger sample rate of 96000Hz takes longer to process) but it outputs faster than the 48000Hz?
Surly a longer processing time should equate to a longer output time!
Also the buffer should make no difference once its been processed as the buffer is the safety net for pre processing.
Guys is this good?
[ATTACH=CONFIG]22066[/ATTACH]
High sample rat is important… 96 seems to be a standard.
Why, tempo adjustment, stretching, at 44.1 your sound will tear up. 96k, you can get away with larger tempo adjustments. Studio techs will use 88.2 because it dithers down to 44.1 well.
