Hi
I’m currently running Cubase 10.5 and have a RME AIO card as my interface.
Like many others I am experiencing problems using the external effects routing.
The sound is coming through fine, however Cubase seems unable to report/calculate the delay for the AD/DA round trip.
No digital outboard gear is being used and I’m sending and return through the analog breakout cables.
Other users have reported that it’s because of Cubase not calculating negative delays??? However these messages appear to be from years ago and I did see someone somewhere say it now works for them with the RME aio …
It’s not really a problem with mono sources. But as I only have 1 channel of outboard gear and plan to use on individual tracks (then render in-place) on multi mic sources, I really need to get this sorted to prevent phase and comb-filtering etc. as I would like to mix the tracks in context with each other too.
Any work around anybody know of?
Or know of any setting/preferences I maybe missing in cubase or RME totalmix?
The reason why you need ‘negative delay’ is when the asio interface reports false i/o latency to the host. When it reports smaller delay value than real, it can go negative. On some RME, there are 32samples buffer on output exists in addition to normal ASIO buffer, and this is perhaps the source of the problem.
Usually, the value should be positive which means the signal is delayed by that amount. Negative amount there means the signal returns before cubendo sends out the audio, i.e. you have a time-machine somewhere in the connection or the asio driver is reporting untrue value. I guess driver for your interface is the latest? Maybe you should report this to RME, I don’t think it is wise to fix it on the host side because the driver reports the wrong value in the first place.
@Dr.Strangelove
Hmm, then perhaps the source of the problem isn’t that however ‘negative delay’ must be a from false latency value.
In my case, all my ad/da connected to hdspe madi has latency up to 2ms. Round trip of 1ms via ad/da is very usual as you know. ‘Negative delay’ means the signal came back earlier than expected even with the ad/da latency on top.
Just checked it, At 256 samples buffer at 48KHz on mine shows input = 5.375ms and output = 6.063ms in nuendo. 5.375 is 256 / 48000 and 6.063 is about (256+35) / 48000, so yes that extra buffer is reported.
I wonder what happens when you raise the asio buffer to maximum/minimum when the external effect panel cannot report the value.
this ‘negative delay’ thing has been reported for years and years - and RME blame Steinberg and Steinberg blame RME
If you are using external A/D D/A then the interface can’t report back the total ASIO delay because it can’t possibly know. Why the ping function can’t just sort all this out I don’t know…
If you are using external A/D D/A then the interface can’t report back the total ASIO delay because it can’t possibly know. Why the ping function can’t just sort all this out I don’t know…
The ping function is not like ping in TCP I/P term or alike as you know.
It’s just an audio impulse. It sends out an audible impulse to a D/A then received back to an A/D, and cubendo measures the time between send and return.
Thus that measures the delay of D/A and A/D as well as all the delays made by the audio interface including delays of dsp mixers in e.g. UAD (that has quite a big amount of delay). The input and output buffer size is known to the host so it is already subtracted from the result shown in the external effect panel.
Even if you try AES/EBU or SPDI/F loopback, it at least delays by 1 sample. If going out to analog, that usually be more than 1ms.
hi Takashi - yes I understand what it’s doing and of course ‘in real life’ it can’t be negative - and yes it could be because of inaccurate reporting by the ASIO driver - but I don’t understand why it can’t be negative…ie ping just fixes the problem ? It could just analyse the wave like you have to do manually if you have the issue.
I appreciate the input @TakashiWatanabe@Dr.Strangelove i’m definitely not at your level of understanding.
I have tried changing the buffer size with no luck and im all up to date driver wise.
Another user (that got it working apparently) said it had to do with “direct monitoring. That needs to be off in cubase and totalmix .”
but I’m not sure how that would help?
to figure out the delay, the closest fix I’ve found is to duplicate the track, flip the phase, and with a delay on the main track in the inspector by around plus 0.38ms or 0.37ms the signal gets the weekest (but never quite nulls) although I guess the signal is changing going through the transformers etc.
I guess this around about correct… I think its accurate, by can’t be sure
I also think my outboard reverses the phase when stuff is ran though it, so I’ve compensated for that in totalmix on the hardware outputs.
its not ideal as I still cant quickly flip between insert in and out (without having to reset the delay)
think that’s a coincidence (red herring!) - and if you switched it off in cubase you don’t actually need to do that in totalmix too
but anyway…
There is definitely a probable bug…or rather a disagreement between RME and Steinberg on how it should work. The issue is that SB don’t allow the so called ‘negative delay’ meaning if the audio comes back earlier than expected compared to the reported ASIO latency then it can’t correct for it.
All the other reports of people ‘fixing’ it seem to rely on voodoo on random clicking - but AFAIK the ‘negative delay’ thing has never been ‘fixed’.
Your workaround is fine - although you could test it better by sending the FX a very short blip and aligning by hand…also if you put a delay in the insert of that track (rather than using inspector delay)…when you bypass all the plugins then it will bypass the delay too ?
but I don’t understand why it can’t be negative…ie ping just fixes the problem ?
Yeah, it is certainly doable to make a change in SB side to measure the negative value but the same latency figures for in/out are also used to place recorded audio samples.
If the latency value is incorrect then the recorded audio will also be displaced, that’s no good, right? So devs@SB might be thinking instead of making a little workaround only for the external effect panel, the driver should report the correct value. This kind of philosophy appears in other areas in Cubendo, maybe that is not just for SB but it is a good way to keep big programs clean, I guess.
17/48000 = 0.375, we are talking about analog audio here so there aren’t definite value == never quite null, but we can say the ‘error’ is by around 17 samples.
@TakashiWatanabe I’m not suggesting they ‘break’ the existing ASIO reported latency for recorded tracks but this seems not to work for specific external FX scenarios - and in these circumstances you can actually change that latency manually (in the FX panel). SB give you that option…why not allow these to be negative numbers and why not make the ping work in these circumstances ?
If it’s possible to fix this by hand as the OP has done then Cubase/nuendo should be able to do it automatically.
In fact the whole external FX section needs some urgent attention - but that’s been true for many years…
@Dr.Strangelove amazing ill try the blip and @TakashiWatanabe awesome ill download this. thank you. (I did try with the stock delay but for some reason it wasn’t accurate)
I’m really happy with both Cubase are RME in all other aspects. such a shame about this. I hope they get it fixed one day.
I’m not suggesting they ‘break’ the existing ASIO reported latency for recorded tracks but this seems not to work for specific external FX scenarios -
No no, I am saying if the latency value used for the external FX ping calculation is wrong, then all the audio recorded on audio tracks using the same interface are also misplaced because Cubendo uses the same reported figure to place incoming buffers on audio tracks.
The problem can only be revealed when you move the project to another system or change interface, but if an interface records audio 17samples off against another, that should also be fixed, imo. The fix to ‘this’ problem can only be done by the interface’s vendor, and the same ‘fix’ also fixes the external efx problem.
I understand your point, though. It allows us to make the signal coming through external efx earlier, then why not later? That’s very natural request…
BTW, one thing I don’t quite understand yet is when going in/out through an AD/DA, there’s always a much bigger amount of delay than 17samples caused by the analog to digital conversion. That is usually about 1ms=48samples or bigger. It seems to me that the negative value of 17samples should be masked by this 48samples.
I just came up with an idea. What happens if you connect your RME interface like this,
Cubase EXT FX OUT-> RME D/A out 1->a cable-> A/D input 2->HDSP MIXER->D/A output 2->a cable->RME A/D input 1->Cubase EXT FX IN
This way, you can measure the latency of RME A/D & D/A minus the entire error. If you see any value in the external efx panel with this test, we can maybe tell where the problem really lies. I should try this myself.
I think on RME the extra buffer samples are on the output - so maybe not relevant in most cases when recording.
There are so many places that are correcting for system delays / ASIO latencies / plugin latency / asio guard etc…it’s hard to know what is the CORRECT time. In most cases 1ms wouldn’t make too much difference on a microphone signal but when you are using parallel processing on an external effect it could make a huge difference.
I’m hoping that for day to day use the ASIO latency reported by RME is correct and this only falls down when using external FX ?
My AD/DA figures are:
Analogue interface input (ADC): 43 samples
Analogue interface output (DAC): 28 samples
and, as you say, you think these numbers would mask any need for ‘negative delay’
ok, despite this giving me a headache for nearly a year. Randomly tried the ping function and it worked no idea why, but early Christmas present.
didnt work yesterday… nothing on my end has changed…maybe some auto update on windows, rme or cubase drivers happened…
Merry Christmas to me
Here is what I’ve been able to figure out. My RME card (an hdsp9632) reports a 32 sample delay based on its internal AD/DA converters. Unfortunatly, I have some analog equipment hooked up to an 8 channel AD/DA converter on the cards ADAT ports and set up as external effects. If I record the outputs of that equipment, everything is shifted earlier by exactly 64 samples, which means that there is a -32 sample offset on the ADAT input ports and a -32 sample offset on the ADAT output ports. If I run the same tests with the built in i/o, everything comes back sample-accurate. That means that the card would need to report at least 2 different delay offsets to Cubase, and I don’t think that thats possible with ASIO. My solution is to add a delay plugin (Voxengo Sound Delay set to 64 samples) before each instance of the hardware plugin. This of course is not much help for External keyboards, but my main concern was with parrallel prosessing anyway.
this is true - but it doesn’t need to be this complex…Cubase/nuendo could just ping the external effects chain and save this value as part of the FX setup - it cannot possibly receive the ping before it sends it… IGNORE the reported ASIO delay . Anything else is overcomplicating it.
Right, if Cubase could make use of negative numbers. If they were to ignore the reported delay, the built-in converters would come back 64 samples late.
no idea why, but early Christmas present.