I would record in 96 kHz only if this is a real must, if you have i.e. special quality requirements for Classic or Jazz recordings.
If this is not really required do yourself a favour and stick to 44.1 kHz, its enough quality in terms of sample frequency.

But very important is, that you record with at least 24bit. This offers a higher dynamik range, so that you can have higher
"safety buffers" for Gain settings on your inputs .. to work with -12db ... to work in safer distance before 0dB ....
One of the advantages is, that you have in the final mix more headroom for postprocessing / mastering.
Other advantages: in the case of recordings with very big dynamics (Classics) you record the very silent signals with more bits as if you would have with only 16bit depth. Also the distance to the "noise floor" is higher.

Then you mention a Buffer size of 4096. Well I think you mean the ASIO Buffer size.

This value of 4096 is very very high. I use usually between 64 .. 256, in rare cases either 32 or 512.

On the one hand a buffer of 4096 saves much CPU time, as the CPU does not need to be very busy to transfer data in time, as much becomes buffered, but the end to end Latency between the Recording Interface to the DAW and back will have longer time to travel...

Which leads me to your last question in terms of Zero Latency. There is no "Zero Latency".
There is always a little latency, as the signal conversion from analog to digital needs always a little time.
And also the way from your recording interface via PCI/PCIe/USB/Firewire to the PC/DAW and back to the recording Interface, where your Headphones are connected.
So .. if you want to hear on the headphone the Music, like you Mix/Master it on your DAW including additional Effects and such, then there will always be latency.
And this Latency you make much bigger, by increasing the ASIO Buffersize to the highest value which is possible (here 4096)
because audio will be processed now in bigger chunks of 4096 Samples Buffersize.
On the other Hand ... if you take the lowest value possible, which might be 48 samples or even 32 samples on PCI/PCIe based solutions, then the CPU needs to hurry, that no Audio Data gets lost, as the buffering is now lower.
This increases the CPU time and the likeliness to loose data .....

Should you have an Audio Project, where you use a lot of VSTs (EQs, Compressor, etc) and eventually even virtual instruments, then the CPU has a lot of things to calculate. Depending on how exactly the Performance of your System is and how complex / CPU intensive the project is, then it can be the case that the CPU can't be quick enough, Audio Packet loss can happen and then you hear Audio interruptions or clicks ....

In such a case, depending on your DAWs capabilities, you have possibilities to workaround
a) in Cubase you can freeze tracks
b) you can make a dowmix and record your stuff to the downmix, then the complexity is away and you can eventually record with only 32 / 48 samples ASIO buffer.

But in most cases you might not want or need to hear the Mix that comes from the DAW ....

Near Zero latency you get best, when you listen to all the signals in i.e. Phones that come directly from your recording interface.

So if you record Guitar or Vocals to a "playback track", then configure the routing in such a way, that on your phones you directly hear the signals that you record with your recording interface and also hear the playback.
Then you have only the very very low latency of the A/D converters ... plus D/A conversion to your headphones.

So ... you can shoot potentially into your own knee by using maybe much too high ASIO buffers like in your case now (4096).

With RME you have proven products with excellent drivers which have already a very low latency, so this is already a very good basement.

With more experience and workflow optimizations you will over time use your gear in the best possible way.

I hope my comments inspire you to work on your setup and find something which fully fits your demands.

Hi,

thanks for the advice with loopback recording. This is what I have come to:

All the recordings made via Loopback in Total Mix are aprox. 0,53 ms delayed after the original track.

All the recordings made via cable loopback (output plugged into another input and recorded) are delayed more than the Total Mix loopback recordings. Here are the results:

Cable loopback, DSP for Record off: 0,76 ms after the original track.
Cable loopback, SDP for Record on: 0,80 ms after the original track.
...As you can see, checking the option "DSP for Record" adds 0,04 ms latency. 

I have figured that, the latency does not depend on turning EQ and Dinamics on/off. It changes only by checking or unchecking the option "DSP for Rerord". I find this a bit strange, because even if the EQ and Dinamics are in the recording path, there should be no extra latency when I turn them off (in my opinion). However, the extra 0,04 ms latency appears simply after checking the DSP option, no matter whether the EQ and Dinamics are on/off. On the other hand, there is no extra latency when the DSP option is unchecked, but the EQ and Dinamics are on. Is this right?

There is also another issue. After recording countless amount of tracks, I have found out, that the very first recording, which I make after connecting my interface to PC, is always out of synchronization. It is usually 0,04 ms "before" the results above. It gets fixed when I ajdust the Buffer size in the Fireface USB settings. Please don´t misunderstand me: I get these 0,04 ms always - even if the Cubase was already set to 4096 kHz and so was the Fireface. It simply helps to switch Fireface to (for example) 2048 kHz and than to 4096 kHz again - problem fixed. I don´t believe that this is a common issue, is it?

It helped me to install new drivers. A lot of issues disappeared. This one ramains, however. Before I installed the new drivers, my latency was changing with different buffer size - even when I used to set the same buffer size in Fireface settings and Cubase settings too, the latency used to be different with 4096, 2048, 1024 kHz etc. This problem was solved by installing the last drivers.
Can you assure me that everything is in order, or tell me what it is that I am doing wrong?

Can you assure me that everything is in order, or tell me what to do next?

Thanks for help and patience.

Hi,

I have done what you asked me for. It is much easier and faster to work with with the RTL utility then measure the milliseconds in Cubase, indeed. As you can see, I have done three tests with buffer size 2048, one test with buffer size 1024 and one with 512. Interresting is, that all the three tests with buffer zize 2048 ended up differently. RTL did not report any issue only when the buffer size was set as 512, the meassured amount of samples seems too high in this case as well, though.

Do you have any idea what can be the issue? I have recently updated my Windows from Vista to Windows 10. Can the issue be on this side?

Please see the screenshots with all the reports.

Sorry for the very late response,

I have downloaded the latest drivers for Windows 10. I made sure that the drivers for USB work properly. Yet, the results were still the same. I have borrowed another PC (also Windows 10), downloaded latest drivers etc., but the results were the same. My own PC has USB 2, the one I borrowed has USB 3, I tried all the ports in both cases. I hope that the links work for you now. Any idea about anything I do wrong?

https://uloz.to/!vAdeWnPrQ/512-nr-1-png
https://uloz.to/!AWovaynJM/1024-nr-1-png
https://uloz.to/!buuoWtQMs/2048-nr-1-png
https://uloz.to/!aCn7rajVd/2048-nr-2-png
https://uloz.to/!Y5xQfQExC/2048-nr-3-png

I corrected the RTL Utility settings. Here, you can see the new results and my setting in Cubase as well. I believe that the Cubase settings are alright.

https://uloz.to/!oh7eP9jfL/snimek-obrazovky-710-png
https://uloz.to/!5rEbVUz7N/snimek-obrazovky-711-png

Here is better pictures with the correct RTL Utility setting and Cubase settings. As you can see, the measured latency still differs from case to case.

https://s5.postimg.org/u4cbtlrav/Sn_mek … ky_710.png
https://s5.postimg.org/bdezx6m47/Sn_mek … ky_711.png
https://s5.postimg.org/3ly9ymhyv/Sn_mek … ky_716.png
https://s5.postimg.org/6u2rbo48n/Sn_mek … ky_717.png
https://s5.postimg.org/ebbyqvtrr/Sn_mek … ky_718.png