Using Dante and Firewire Interface together?

357 views
Skip to first unread message

Andrew Blizzard

unread,
Jan 22, 2015, 3:22:46 PM1/22/15
to ql...@googlegroups.com
Hey all,

I am in the midst of planning an upcoming design and have a quick question. Is it possible to use a firewire interface and Dante Virtual Souncard (sending to a Dante-MY16-AUD) at the same time? Would I need to set them up as an aggregate device?

Thanks,
A

Lists

unread,
Jan 22, 2015, 3:28:26 PM1/22/15
to ql...@googlegroups.com
yes, 
and you can either use them as separate patches (each cue can only go to one patch) or create an aggregate device.
Charles Coes
cco...@gmail.com
www.charlescoes.com
"Why shouldn't truth be stranger than fiction?  Fiction after all has to make sense" - Mark Twain

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53

---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Andrew Blizzard

unread,
Jan 22, 2015, 3:45:35 PM1/22/15
to ql...@googlegroups.com
Okay thanks. What is the general consensus with running two interfaces without setting them up as an aggregate device? Is it reliable? 

Joshua Langman

unread,
Jan 22, 2015, 3:59:42 PM1/22/15
to ql...@googlegroups.com
Should be. I would rather run them as separate devices than as an aggregate; it should be more stable that way.

Nigel Hogg

unread,
Jan 22, 2015, 4:02:13 PM1/22/15
to ql...@googlegroups.com
I've used Dante over an MY 16-AUD and the built in USB interface in an 01v96i for 2 years without any problems whatsoever. Very simple setup and very reliable.
Nigel

Andrew Nagy

unread,
Jan 22, 2015, 4:12:03 PM1/22/15
to ql...@googlegroups.com, ql...@googlegroups.com
I'm running a show now with a motu 828mk3 and dante on the same machine. It works perfectly. I'm even sending smpte from qlab over dante and there aren't any issues. 



On Thu, Jan 22, 2015 at 12:59 PM, Joshua Langman <jlangma...@gmail.com> wrote:

Should be. I would rather run them as separate devices than as an aggregate; it should be more stable that way.

--

Sam Kusnetz

unread,
Jan 22, 2015, 4:36:12 PM1/22/15
to ql...@googlegroups.com

Andrew Blizzard wrote:
> Okay thanks. What is the general consensus with running two interfaces
> without setting them up as an aggregate device? Is it reliable?

As long as you don't need one cue to play to both interfaces at the same
time, using two (or up to eight) interfaces independently works quite
nicely.

I would advise avoiding aggregate audio devices where possible, as they
increase the processor load and can sometimes involve clocking headaches.

Cheerio
Sam
--
Sam Kusnetz | Figure 53 Field Operative
s...@figure53.com

Andrew Blizzard

unread,
Jan 22, 2015, 4:50:12 PM1/22/15
to ql...@googlegroups.com
This is all great. I am needing to up my channel output capacity from 16 to 24 and adding a second interface might be the best way for me to do it. 
I am the designer so anything I need to add will be a rental and comes out of my budget. So needless to say purchasing a Dante card is out of the question now. 

If I were wanting to have an audio file play to both interfaces at the same time, I would need to duplicate the cue and repatch to the second interface correct? What kind of sync issues would I encounter doing this?

Christopher Ashworth

unread,
Jan 22, 2015, 8:26:56 PM1/22/15
to ql...@googlegroups.com

(mobile)

> On Jan 22, 2015, at 4:50 PM, Andrew Blizzard <abl...@gmail.com> wrote:
>
>
> If I were wanting to have an audio file play to both interfaces at the same time, I would need to duplicate the cue and repatch to the second interface correct? What kind of sync issues would I encounter doing this?

The devices have separate clocks, and without the aggregate to manipulate the signal the streams will not be in frame accurate sync. They will each run on the clock of the respective devices. The degree to which this matters depends on what material you're sending to the devices.

C

Andrew Blizzard

unread,
Jan 22, 2015, 8:57:52 PM1/22/15
to ql...@googlegroups.com
Could I not then clock the two of them to an external clock without setting them up as an aggregate device and achieve accurate sync?

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab

Follow Figure 53 on Twitter: http://twitter.com/Figure53

---
You received this message because you are subscribed to a topic in the Google Groups "QLab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qlab/xHrWzdFyH4A/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qlab+uns...@googlegroups.com.

Andy Lang

unread,
Jan 22, 2015, 11:14:02 PM1/22/15
to ql...@googlegroups.com
On Thu, Jan 22, 2015 at 8:57 PM, Andrew Blizzard <abl...@gmail.com> wrote:
> Could I not then clock the two of them to an external clock without setting
> them up as an aggregate device and achieve accurate sync?

You would have clock sync, but would not necessarily be guaranteed
that the signals themselves are in sync. That is to say, once started,
the signals would not drift from each other, but you wouldn't have a
way to guarantee that both devices were ready for the first sample of
data at the same time. The
only way to do that is via an aggregate, in which case the OS does
some trickery under the hood to get things synced up.

That all said, if those signals aren't being summed after the fact,
I'm skeptical that anybody would notice a couple samples drift between
two discrete signals, so I wouldn't sweat it.

(If doing an aggregate, clocking both devices together is still of
utmost importance; the aggregate only solves the starting-in-sync
problem.)

Hope this helps,
Andy

Lists

unread,
Jan 23, 2015, 8:36:22 AM1/23/15
to ql...@googlegroups.com
I agree with andy here - though you'd want to do similar outputs on the same devices (main L/C/R on the same, surrounds on the same), so that anything where a few fractions of a milliseconds of delay (really a big shift in samples) won't throw you off....
Charles Coes
cco...@gmail.com
www.charlescoes.com
"Whether we like it or not we are amphibians, living simultaneously in the world of experience and the world of notions, in the world of direct apprehension of Nature, God and ourselves, and the word of abstract verbalized knowledge" - Aldous Huxley.
> --
> --
> Change your preferences or unsubscribe here:
> http://groups.google.com/group/qlab
>
> Follow Figure 53 on Twitter: http://twitter.com/Figure53
>
> ---
> You received this message because you are subscribed to the Google Groups "QLab" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.

Andrew Blizzard

unread,
Jan 24, 2015, 10:57:05 AM1/24/15
to ql...@googlegroups.com
Thanks for the advice everyone. I might have to test a few things to find what is most stable, and what fits my workflow best. Not being able to use one cue and fade from house to stage (each will have a dedicated interface if I use two without aggregate) is problematic. But things are getting clearer thanks to everyone here.

Cheers,
Andrew
Reply all
Reply to author
Forward
0 new messages