Strange readings new audio interface

[Spiritos]

Installed my new Steinberg UR44 today. Didn't encounter any problems but have some questions about the settings and latency values. Will say I'm not familiar with the exact workings of bits/kHz etc. so I might miss something simple or just don't understand things correctly.

In Live 9 (64x)

Samplerate 96000 / Buffersize: 128
Input Latency: 3.83 ms
Output Latency: 4.83 ms
Overall Latency: 8.67 ms

Samplerate 96000 / Buffersize: 192
Input Latency: 4.50 ms
Output Latency: 5.50 ms
Overall Latency: 10.0 ms

Samplerate: 48000 / Buffersize: 64
Input Latency: 4.08 ms
Output Latency: 5.06 ms
Overall Latency: 9.15 ms

Samplerate 192000 / Buffersize: 256 (can't select a lower buffersize)
Input latency: 3.68 ms
Output latency: 4.68 ms
Overall latency: 8.36 ms

Sonar (x64):

Samplerate: 96000 / Buffersize: 128
Input latency: 3.1 ms
Output latency: 3.5 ms
Overall latency: 6.6 ms

Samplerate: 96000 / Buffersize: 192
Input latency: 3.7 ms
Output latency: 4.2 ms
Overall latency: 7.9 ms

Samplerate: 48000 / Buffersize: 64
Input Latency: 3.9 ms
Output Latency: 4.8 ms
Overall Latency: 8.7 ms

Samplerate 192000 / Buffersize: 64
Input latency: 1.0 ms
Output latency: 1.2 ms
Overall latency: 2.2 ms

First thing I notice is when selecting a ridiculous high samplerate like 192 kHz, the lower the overall latency.
Now I'm an absolute novice in understanding these ratios but that doesn't seem right does it? Especially since the same buffersize with a lower samplerate is is 4x higher.

Also when I select 192000 sample rate in Live I cannot choose any lower buffersize than 256 samples while in Sonar I can drop down to 64. Why is this?

And in general: Is Live so much 'worse' that all latency values are +/- 25% higer than in Sonar?

[BertKoor]

In theory:

Code: Select all

elapsed time = samples / rate

Your Live 9 data:

• 128 / 96kHz = 1.33 ms
• 192 / 96 kHz = 2.00 ms
• 64 / 48 kHz = 1.33 ms
• 192 / 256 kHz = 0.75 ms

In order to do good comparisons, you should vary just one thing.

• Difference between first & second measurement is a raised buffer size: extra 0.67 seconds latency in theory. In practice you see it raised by 0.67 ms for input & output, so that is totally according to theory.
• Compare first & third measurement: halved buffer size & halved sampling rate. Same latency in theory, but in practice it's in average 0.24 ms off. It surprises me that the lower sampling rate gives slightly more latency, since your system has less data to process in the same time.
• This data does show that the latency is significantly bigger than what's expected in theory. About 2.5 ms is unaccounted for, and that must be due to the host or driver or whatever.

Your Sonar data is simular.

[Spiritos]

Hi Bert,

Thanks for your explanation. It is in fact the very first time someone is able to explain me the ratios in less than a page Tnx! I still need to get a more firm grip on the theory but I'm learning as we type... Two questions about the 192 / 256 or 64 setting in Sonar vs. Live.

- Would it be correct to assume Sonar is better written than Live since it's latency is so much lower, especially on this setting? And does this also explain why Live can't select a buffer size lower than 256 with 192 kHz while Sonar can go down to 64?

- I did read up on some of the theory and without wanting to start a debate, I read one pov of the debate is that recording with more than 48000 samplerate is overkill, due to the Nyquist effect, in effect increasing your filesize with inaudible frequencies.

But if my aim is to record (monitor and track) with as low a latency as possible can I safely opt for the 192/256 setting, since especially in Sonar it gives such great results and should I simply accept the consequense of dealing with bigger files or are there advantages in going for lower samplerates (48000) but with higher latency?

[BertKoor]

Would it be correct to assume Sonar is better written than Live since it's latency is so much lower, especially on this setting?

Live has in average 2.5 ms unaccounted for on the input, and 3.5 ms on output.
Sonar has in average 1.7 ms unaccounted for on the input, and 2.2 ms on output.
So that conclusion seems fair.

And does this also explain why Live can't select a buffer size lower than 256 with 192 kHz while Sonar can go down to 64?

No, that must have other reasons only known to the Ableton developers. If there's a limit on buffer size 256 for 192 kHz, then it would be consequent if there are also the following limits: 128 for 96 kHz, 64 for 48 kHz.

Oh, now I see I made a calculation error in my first post. The theoretical latency for buffer size on 192 kHz should be 1.33 ms as well

I did read up on some of the theory and without wanting to start a debate, I read one pov of the debate is that recording with more than 48000 samplerate is overkill, due to the Nyquist effect, in effect increasing your filesize with inaudible frequencies.

I also read a simular article discussing the optimum sampling rate, which they said is somewhere around 60 kHz. It's a trade-off between filter design and band width.

But if my aim is to record (monitor and track) with as low a latency as possible can I safely opt for the 192/256 setting, since especially in Sonar it gives such great results and should I simply accept the consequense of dealing with bigger files or are there advantages in going for lower samplerates (48000) but with higher latency?

Imho you should pick a sampling rate first. If you're going to produce audio CD's, I'd pick 44.1 kHz or 88.2 kHz if your plugins don't already oversample themselves. If you're going to work for video projects, pick 48 kHz or 96 kHz.
There are cases where audio interfaces are fixed to 96 kHz internally and let the driver do sampling rate conversion with a sub-par algorithm. So you can defend working in 96 kHz and resample to 44.1 kHz as the last process step while mastering, using the best resampling algorithm you can find.
The sampling rate can have a lot of influence on the working of all your plugins. So deciding on that should come first.

With the sampling rate sorted out, pick the smallest buffer size your system can handle for that project. Maybe a bit larger for safety, so there's a bit of room for the project to grow in terms of CPU power.

Regarding monitoring, does your card offer zero-latency direct monitoring where the input is (still in the analog domain) directly routed to an output? That would be my first choice, but is only possible if the audio you're recording does not need processing first.

[WOK]

About the different ms-values: some hosts also report wrong values, maybe due to miscalculations are just to pretent to be "better". Connecting out and input, sending a short impulse a re-recording it you could see the real latency.
A low latency/low buffer size is only important for live playing VSTi or Guitar effects. Lower buffers and/or higher sample frequency increase CPU-usage.

- I did read up on some of the theory and without wanting to start a debate, I read one pov of the debate is that recording with more than 48000 samplerate is overkill, due to the Nyquist effect, in effect increasing your filesize with inaudible frequencies.

That's only half true. Theoretically, CD-Quality (16bit = 65536 dynamic steps, 44100Hz = 22000 max frequency) is more than the human ear can hear. Practically, the whole 16 bits are only used at the maximum level, so quieter parts in the song get much less dynamic detail. And the old formula "highest possible frequency = 1/2 sample frequency" has a major drawback: imagine sampling a 14700Hz sine tone (the maximum most persons will be able to hear) at a sample frequ of 44100, the computer can "take" 3 samples per original sine cycle, resulting in a square wave. This "square wave" is then used for all audio manipulations inside the DAW. The output filter of the D/A converter later reduces that to a sine wave again. But obviously the result can not be exactly the same like the original signal and depends on the quality of the consumers D/A converter. That's where the sentence "digital recordings sound sharp" is coming from.
Thus it does make sense to sample at higher rates and do the downsampling at the very last mastering step. Of course doubling sample frequency doubles file size and doubles CPU usage for all calculations.

[Spiritos]

And does this also explain why Live can't select a buffer size lower than 256 with 192 kHz while Sonar can go down to 64?

No, that must have other reasons only known to the Ableton developers. If there's a limit on buffer size 256 for 192 kHz, then it would be consequent if there are also the following limits: 128 for 96 kHz, 64 for 48 kHz.

You're right. These mentioned limits consequently apply in Live.

Imho you should pick a sampling rate first. If you're going to produce audio CD's, I'd pick 44.1 kHz or 88.2 kHz if your plugins don't already oversample themselves. If you're going to work for video projects, pick 48 kHz or 96 kHz.
There are cases where audio interfaces are fixed to 96 kHz internally and let the driver do sampling rate conversion with a sub-par algorithm. So you can defend working in 96 kHz and resample to 44.1 kHz as the last process step while mastering, using the best resampling algorithm you can find.
The sampling rate can have a lot of influence on the working of all your plugins. So deciding on that should come first.

With the sampling rate sorted out, pick the smallest buffer size your system can handle for that project. Maybe a bit larger for safety, so there's a bit of room for the project to grow in terms of CPU power.

I do understand that for CD/DVD you need 44.1/48 kHz. Also, I understand that if you're using for eg. samples which are probabaly 96 kHz tops and you choose a higher samplerate your system has to do more conversions in the final stage. It's just in my case where Sonar gives me such good latency with 192 kHz I'm naturally more drawn to using this samplerate. But again, I really have to get a better understanding of how these things work.

Regarding monitoring, does your card offer zero-latency direct monitoring where the input is (still in the analog domain) directly routed to an output? That would be my first choice, but is only possible if the audio you're recording does not need processing first.

The UR44 offers zero-latency monitoring, has onboard DSP and also a loopback function so yeah.

@ Wok: One perspective I read on why higher samplerates give better values is that a PC -when working with 2 channel 48/24 bit- doesn't need to 'work that hard' so other busses are free to be used by other services running. When choosing 192 kHz the free processing power -in this case- is limited, in effect increasing performance since the focus will be primairily on the processing.

So given your explanation you see no disadvantages in using 192 kHz?

[WOK]

@ Wok: One perspective I read on why higher samplerates give better values is that a PC -when working with 2 channel 48/24 bit- doesn't need to 'work that hard' so other busses are free to be used by other services running. When choosing 192 kHz the free processing power -in this case- is limited, in effect increasing performance since the focus will be primairily on the processing.

Nope. Windows is sharing the CPU power between all tasks (in an unefficient way...). If one task takes more processing time for itself (audio), the others get less (graphics, antivirus ...). The more samples per second have to be calculated, the more effects need processing time, the higher the CPU load will go, at the end slowing down even the mouse pointer reaction, until 100% CPU, then audio dropouts will occur because data can not be calculated fast enough for the music output. This problem can be decreased with bigger Asio buffers settings. Also bigger audio files because of higher rates will reduce the total amount of audio tracks which the harddisk (-controller) can handle to transfer for playback.
Using 96khz sample frequency is a good tradeoff, the positive soundeffect of higher rates is not that big against the demands to the hardware.

[Spiritos]

Using 96khz sample frequency is a good tradeoff, the positive soundeffect of higher rates is not that big against the demands to the hardware.

Thanks for your answer. Guess I'll have to find a way to lower the latency some other way then. Having to go from 2ms at 192 kHz to 8-9 ms at 96 kHZ seems so unfair

[hibidy]

The only thing I'm going to add is that with my same soundcard and the same sample rate, I get with my soundcard a total of 5.21ms with live and 5.52 with studio one. With the point being that live should not be significantly higher.

specs:

focusrite saffire 14 (firewire)
48k
64 buffer

[Spiritos]

The only thing I'm going to add is that with my same soundcard and the same sample rate, I get with my soundcard a total of 5.21ms with live and 5.52 with studio one. With the point being that live should not be significantly higher.

specs:

focusrite saffire 14 (firewire)
48k
64 buffer

Hmm.. On another forum I asked someone with a Focusrite 18i20 to compare latency values between Sonar X3 and Live 9 and he also had higer values in Live for around +/- 2 ms per setting (all values taken from the DAW's preference window btw.)

I have no idea if it's a common thing for different DAWs to have significant (1-2,5 ms) other latency values.
With my prior interface Sonar also performed a little better than Live but only about 0.2-0.5ms.

[UltraJv]

Have you actually tried running at 192khz? It will bring your PC to a grinding halt after a few tracks and plugs. Anything above 44.1 is a waste of CPU.

[Spiritos]

Have you actually tried running at 192khz? It will bring your PC to a grinding halt. Anything above 44.1 is a waste of CPU.

Actually it didn't. But I need to do some more extensive testing.

In general I know 44.1 for audio and 48 for video is the max (although some can hear the difference between these two) but an observational question:

If this is the case, why are consumer interfaces manufactured to handle anything above 96 kHz if it's a waste anyway? And are there studios/people who run 192 khZ and if so, for what?

[UltraJv]

Have you actually tried running at 192khz? It will bring your PC to a grinding halt. Anything above 44.1 is a waste of CPU.

Actually it didn't. But I need to do some more extensive testing.

In general I know 44.1 for audio and 48 for video is the max (although some can hear the difference between these two) but an observational question:

If this is the case, why are consumer interfaces manufactured to handle anything above 96 kHz if it's a waste anyway? And are there studios/people who run 192 khZ and if so, for what?

Its a numbers game. All things in tech sell on numbers. Just because youre running it high, dosnt mean there will be any advantage attall. Try one of your old projects and see how it eats your CPU. If youre recording audio for classical its claimed to be worth it, otherwise its pointless. 44.1 is fine.

[Spiritos]

Its a numbers game. All things in tech sell on numbers. Just because youre running it high, dosnt mean there will be any advantage attall. Try one of your old projects and see how it eats your CPU. If youre recording audio for classical its claimed to be worth it, otherwise its pointless.

Although I'm certainly not blind for marketing strategies I can't believe this is all there is to 'it'.
I remember reading somewhere that also if you use distortion or amp simulation the higher frequencies fold back on the audible ones so in that case the audio could also benefit from 192 kHz.

[UltraJv]

Its a numbers game. All things in tech sell on numbers. Just because youre running it high, dosnt mean there will be any advantage attall. Try one of your old projects and see how it eats your CPU. If youre recording audio for classical its claimed to be worth it, otherwise its pointless.

Although I'm certainly not blind for marketing strategies I can't believe this is all there is to 'it'.
I remember reading somewhere that also if you use distortion or amp simulation the higher frequencies fold back on the audible ones so in that case the audio could also benefit from 192 kHz.

There have been many blind tests on KVR for high bitrates. They have all been inconclusive.
Yes youll hear a difference but it seems due to poor programming rather than improved audio quality. YMMV but its subtle. This is quite a good article :

http://varietyofsound.wordpress.com/201 ... ing-rates/