How would the prism do that? Normally the buffersize is set in the driver? Does the Prism have a dynamic buffer?
I’ve spoken to support at Prism Sound support about this and they just said that this is normal. I think it is crazy. My old RME-APOGEE setup always reported the same roundtrip delay no matter what i did. Prism Sound Orpheus drivers are barely hanging on by the skin of its teeth if you ask me.
Wow, that sounds insane, first time I’ve heard of that.
I am having exactly the same issue: when using cubase pro 9.5 in 64 bit the ping works (I can see the signal passing out of the DAC, through the gear it is connected to and back into the ADC), but it always reports 0 as the delay (which is of course wrong, and things are no longer in sync)
Can confirm the ping does not work in 64-bit mode (mac os 10.11)
I do think the latency reporting is broken in general.
Using my Bricasti via AES, each click of the ping button gives a different result, and each result sounds wrong/bad, I end up just having to tune the delay by ear or measure manually.
Can someone at Steinberg please test this out to confirm the issue.
I just found another thread with more people having the delay compensation issue
Still not working in 9.5.10.
Proof there’s a real fundamental problem with 64 bit delay compensation beyond just pinging external hardware.
I totally agree. If I remember correctly, it worked in CB 8.5 but not always and the results would vary. It got better in CB 9.0.
Not sure whats affecting this to not work properly in 64 bit, but it’s probably not a minor issue.
Unfortunately, this has been broken for a VERY long time for some people - even in 32-bit mode. Check out this thread:
Good catch. Thanks!!
Confirmed still not working in 9.5.1. Such a shame.
I might be kicking in open doors here but just as a tip you should always measure “ping” with a dry signal.
If you have any kind distortion or reverb or such there is a chance you might get a slightly off delay measurement because cubase is trying to measure a very short ping.
If ýou have a digital reverb unit for instance you should set it to 100% “dry” before you measure. That way you get both your D/A-A/D delay and the delay you get from the digital reverb unit itself (as an example).
It sucks because using 64 bit actually is more efficient on my system but I cannot use it due to the ping not working in 64 bit mode.
I’m still waiting for someone at Steinberg to let us know that they are at least aware of this.
First, I am waiting for a fix my self
Second, Switch to 32 bit mode, do your pinging and save your external plugins (and/or write down the delay settings). Then switch back to 64 bit mode…
^^^Cheers for the workaround Carvin Man.
The delay settings are saved so no need to write them down. Just switch back to 64bit engine and they’re there.
Still a fiddle about IMO.
I agree, and I actually mentioned the same workaround in a previous post.
This is only effective when and only using 1 external FX at a time. What if you need to eq and compress or even run your signal thru 2 fx 'pieces of gear before coming back into Cubase? This is where the delay ping is required. Who’s not to say that 64 bit processing doesn’t add some delay… how would one know since it’s not working in 64 bit
we have a couple of threads going discussing this, but this has been reported now that we have a full repro.
Glad to hear that. Thank You!!
To put it bluntly, I don’t think anyone in this thread understand how this feature works.
If you have a interface with a fixed-latency driver (which is the case with my Apollos), Cubase already knows about your interface round trip delay. This is the starting point ‘guess’ that Cubase takes to give the correct delay compensation in your DAW. So if you do a Ping test and get a ‘0’, that means the guess was correct and everything is working as it should.
So again if you directly route a cable from your interface output 1 to your interface input 1 and did a ping test, … it SHOULD report 0. Whether your buffer setting is at 32 samples or 1024 samples. Cubase already pre-emptivley knows about this delay… so the Ping test is for calculating any ‘extra’ stuff…
If you have mostly Analog Outboard gear, (which has no inherent latency or delay) this should mostly read 0. However, if you have something like a ADAT output converter, or other digital process or digital FX that has some latency to it…this is where Cubase tries to calculate that and compensate it for you. Its possible your interface itself might have some onboard-DSP processes that introduce extra latency beyond the advertised ‘guess’ too.
At leasts that is how I understand how it works.
If you have an interface driver that constantly changes latency…then Cubase cant really help you much. Otherwise, like someone said, just make sure before a final bounce to Ping everybody.
digi001, I completely disagree with your assessment and your understanding of the issue. Have you exited recorded audio to an analog external device and then returned it to the Cubase Project? The ping test exists and there’s a reason why it exists, and, trust me, not for the reasons you suggest.