Printable View
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 :confused:
Also the fact we have (padi) both have mac books and the S4 yet your time is so low :confused:
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 :P )
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.Quote:
Originally Posted by xtianw
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 :confused:
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.
"Also if I lower the sample rate the output time go's up"
http://imagemacros.files.wordpress.c...6/lol_wut1.jpg
[ame="http://en.wikipedia.org/wiki/Digital_audio"]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"@@AME PARAM@@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!Quote:
Originally Posted by Remote
If I LOWER the sample rate the output time go's UP!
absolutely. let me try to formulate it in different words.Quote:
Originally Posted by Remote
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.