Hi,
I assume that sw version 2.1 brings in group to group routing option… Any information what will be the inner latency? I presume that somewhere between 0.7-1.4ms. Any information yet?
There’s no information available because it’s not a real feature yet. I only just heard about bus-to-bus routing enhancements rumor this morning.
That said, we can certainly speculate. The analog in to analog out latency is only 0.7ms. I would assume that since you wouldn’t be needing to run the signal through the AD/DA converters again, it would be less than that.
It’s been a while, but at one point in time I measured the difference between an input going straight to a group and an input going to a group and then the Ext In of another group. From what I remember, difference was between 5-7 samples.
And I seem to recall that going input > group > group Ext In > matrix > channel was approximately 32 samples.
There’s also the question of whether or not they will attempt to automatically compensate for that latency or just leave it up to the user to manually delay the shorter path.
1 Like
I had a friend at infocom that saw the Group to group happening. And was told by a rep that it will cost 4 samples of latency (same as Dyn8)
3 Likes
Wow, really? That’s cool. I wonder when that update will come.
sooner rather than later I hope!
1 Like
yup, I also heard 4 samples from a friend at infocomm. also heard 2-3 weeks release time, from then, which would be a week or 2 now theoretically 
3 Likes
Sounds very promising! I know this is still only speculation but do you know or can you estimate will this additional 4 samples be ”included” and latency compensated to present 0.7ms or will it increase that a bit? I have understood that the present architecture allows AD to DA latency be that 0.7ms if only using dLive’s own routing options without routing back to channels and again back to master or submasters.
It looks like 0.000041 s of latency will be generated but it’s so specific to use group to group, because you can do that with Mix Ext In and not add latency, I’ve doing really complex signal paths with Mix Ext In and without latency…
I will just to ”need” route BD group and SN group to Drum group so this latency won’t be an issue. 
My gut says no, because they don’t compensate for the 4 samples of latency incurred by the Dyn8 processor either. Then again, perhaps the lack of compensation on that has less to do with Dyn8 and more to do with the fact that it occupies one of the insert blocks. Maybe the insert blocks are just excluded from the latency compensation entirely.
Others with hands on experience with the new feature might be able to offer more input.
If you only have one group you need to route into another group, Ext In works fine. But that limitation is exactly why people have asked for full group to group routing capabilities.
Also, while I’m not sure about your claim that there isn’t any additional latency by using Ext In, it is worth noting that latency isn’t compensated when sending a bus to Ext In.
I’m 100% speculating, but I doubt the 4 sample (or whatever it ends up being) extra latency will be compensated for in group to group routing. There are too many variables (way to route) for the system to account for all of them - especially if the system ends up allowing group → group → group routing. If that routing is allowed, there is no way the system is going to calculate the total latency for you.
I think the only logical choice is to leave it up to the user to account for the 4 samples per “group to group” routing loop.
1 Like
Totally agree. And as you and others have stated before, that extra signal path length is really only detrimental to parallel paths. This change wouldn’t mean that users suddenly need to time align all the sources in their console.
1 Like
Now we know (from the manual):
Group to Group routing is not delay/latency compensated. Group to Group routing adds 4
or 8 samples of latency depending on source point selection (Post Comp or Post Delay
respectively).
3 Likes
I can easily live with this. 
4 or even 8 samples in ms does not ruin my live sound. One ms is approx. same as listening the sound source from the distance of 34cm… 8 samples in 96 kHz is only tiny amount to add to 0.7ms.