Forums > MaxMSP

Udpsend and udpreceive dropping messages

March 19, 2007 | 6:38 pm

I have two machines connect via an Airport hub. The hub is connected to
Road Runner from Time Warner. I am sending very simple messages of the form

n 60 96 1000 1 (note pit vel dur chan)

I am send them one per second and finding that 1 out of 20-30 messages is
dropped.

I have also tried a computer-to-computer link using the built-in Airport
cards. Same deal. I don’t think it is network latency because the messages
should not be leaving my house in any case. The IP addresses are all
10.0.1.x.

Perhaps I missed a thread but are their known issues with udpsend/receive?

Cheers
Gary Lee Nelson
Oberlin College
http://www.timara.oberlin.edu/GaryLeeNelson


March 19, 2007 | 6:51 pm

Hi Gary

I get something similar. That is, every once in a while i receive a
message that my message sent through udp has been delayed 16 or 17
msec. I haven’t actually tested that they are not getting there, but I
have latencies i have to optimize all over the place, Olaf Mathes
wrote at some point that the object was complaining too much.

Don’t know if this helps, but if anyone knows why this is happening
i’d love to get rid of those occasional 17 msecs…

best,

Jaime

On 3/19/07, Gary Lee Nelson wrote:
> I have two machines connect via an Airport hub. The hub is connected to
> Road Runner from Time Warner. I am sending very simple messages of the form
>
> n 60 96 1000 1 (note pit vel dur chan)
>
> I am send them one per second and finding that 1 out of 20-30 messages is
> dropped.
>
> I have also tried a computer-to-computer link using the built-in Airport
> cards. Same deal. I don’t think it is network latency because the messages
> should not be leaving my house in any case. The IP addresses are all
> 10.0.1.x.
>
> Perhaps I missed a thread but are their known issues with udpsend/receive?
>
> Cheers
> Gary Lee Nelson
> Oberlin College
> http://www.timara.oberlin.edu/GaryLeeNelson
>
>
>


March 19, 2007 | 7:03 pm

Jaime Oliver wrote:
> Hi Gary
>
> I get something similar. That is, every once in a while i receive a
> message that my message sent through udp has been delayed 16 or 17
> msec. I haven’t actually tested that they are not getting there, but I
> have latencies i have to optimize all over the place, Olaf Mathes
> wrote at some point that the object was complaining too much.

Well, bur Gary was talking about udpsend and udpreceive and not
netsend/netreceive.

Olaf

> Don’t know if this helps, but if anyone knows why this is happening
> i’d love to get rid of those occasional 17 msecs…

I oculd compile you a version that just doesn’t warn you but would block
anyway if this makes you sleep any better. :-)

Olaf


March 19, 2007 | 7:20 pm

Hi Olaf,

thank you for the offer, but I’ll survive with those 17msecs and
prefer to be warned, its just that i’m not sure if it’s actually doing
it, so i suppose that is good!!

all the best,

Jaime

On 3/19/07, Olaf Matthes

wrote:
> Jaime Oliver wrote:
> > Hi Gary
> >
> > I get something similar. That is, every once in a while i receive a
> > message that my message sent through udp has been delayed 16 or 17
> > msec. I haven’t actually tested that they are not getting there, but I
> > have latencies i have to optimize all over the place, Olaf Mathes
> > wrote at some point that the object was complaining too much.
>
> Well, bur Gary was talking about udpsend and udpreceive and not
> netsend/netreceive.
>
> Olaf
>
> > Don’t know if this helps, but if anyone knows why this is happening
> > i’d love to get rid of those occasional 17 msecs…
>
> I oculd compile you a version that just doesn’t warn you but would block
> anyway if this makes you sleep any better. :-)
>
> Olaf
>


March 19, 2007 | 7:53 pm

I just tried jit.net.send/recv and net.maxhole. Both are much worse than
udpsend/receive. The later at least keeps tempo. Just leaves note out now
and then. Should I try netsend/receive?

On 3/19/07 3:03 PM, "Olaf Matthes"

wrote:

> Jaime Oliver wrote:
>> Hi Gary
>>
>> I get something similar. That is, every once in a while i receive a
>> message that my message sent through udp has been delayed 16 or 17
>> msec. I haven’t actually tested that they are not getting there, but I
>> have latencies i have to optimize all over the place, Olaf Mathes
>> wrote at some point that the object was complaining too much.
>
> Well, bur Gary was talking about udpsend and udpreceive and not
> netsend/netreceive.
>
> Olaf
>
>> Don’t know if this helps, but if anyone knows why this is happening
>> i’d love to get rid of those occasional 17 msecs…
>
> I oculd compile you a version that just doesn’t warn you but would block
> anyway if this makes you sleep any better. :-)
>
> Olaf

Cheers
Gary Lee Nelson
Oberlin College
http://www.timara.oberlin.edu/GaryLeeNelson


March 19, 2007 | 7:59 pm

I suppose this is slightly off-topic. Has anyone added an outlet to udpsend? This is really necessary when requesting information from SuperCollider’s scsynth.

>From the SuperCollider command reference:

/notify register to receive notifications from server
int – one to receive notifications, zero to stop receiving them.

If argument is one, server will remember your return address and send you notifications. if argument is zero, server will stop sending you notifications.

The "return address" that the documentation refers to is the ip and port of the original /notify command. Thus the client to scsynth must read as well as write to the same port. Since it is not possible to simultaneously bind udpsend and udpreceive to the same port (at least the last time I tried), there’s no way to get information from scsynth via the /notify command…

Thanks,
Brian

> —– Original Message —–
> From: "Olaf Matthes"

> Subject: Re: [maxmsp] Udpsend and udpreceive dropping messages
> Date: Mon, 19 Mar 2007 20:03:16 +0100
>
>
> Jaime Oliver wrote:
> > Hi Gary
> >
> > I get something similar. That is, every once in a while i receive a
> > message that my message sent through udp has been delayed 16 or 17
> > msec. I haven’t actually tested that they are not getting there, but I
> > have latencies i have to optimize all over the place, Olaf Mathes
> > wrote at some point that the object was complaining too much.
>
> Well, bur Gary was talking about udpsend and udpreceive and not
> netsend/netreceive.
>
> Olaf
>
> > Don’t know if this helps, but if anyone knows why this is happening
> > i’d love to get rid of those occasional 17 msecs…
>
> I oculd compile you a version that just doesn’t warn you but would
> block anyway if this makes you sleep any better. :-)
>
> Olaf

>


March 19, 2007 | 8:06 pm

besides that ocassional delay it works very well, i think you should
try it… let me know which one works better for you.

J

On 3/19/07, Gary Lee Nelson wrote:
> I just tried jit.net.send/recv and net.maxhole. Both are much worse than
> udpsend/receive. The later at least keeps tempo. Just leaves note out now
> and then. Should I try netsend/receive?
>
>
>
>
> On 3/19/07 3:03 PM, "Olaf Matthes"

wrote:
>
> > Jaime Oliver wrote:
> >> Hi Gary
> >>
> >> I get something similar. That is, every once in a while i receive a
> >> message that my message sent through udp has been delayed 16 or 17
> >> msec. I haven’t actually tested that they are not getting there, but I
> >> have latencies i have to optimize all over the place, Olaf Mathes
> >> wrote at some point that the object was complaining too much.
> >
> > Well, bur Gary was talking about udpsend and udpreceive and not
> > netsend/netreceive.
> >
> > Olaf
> >
> >> Don’t know if this helps, but if anyone knows why this is happening
> >> i’d love to get rid of those occasional 17 msecs…
> >
> > I oculd compile you a version that just doesn’t warn you but would block
> > anyway if this makes you sleep any better. :-)
> >
> > Olaf
>
>
> Cheers
> Gary Lee Nelson
> Oberlin College
> http://www.timara.oberlin.edu/GaryLeeNelson
>
>
>


March 19, 2007 | 8:51 pm

I just did a benchmark on udpsend/receive. I am sending messages like these

n 60 64 250 1 (for makenote in the receiver)

Every 250 ms. I am measuring the interval between the arrival of messages
and find +/- 5-6 ms deviation. Pretty good considering most conductors are
happy with 50 ms. Still, it’s the dropped notes that are bothering me. I
put counters on both ends and find that 4-5 notes are dropped out of a
thousand sent sigly at 250 ms intervals. Again, pretty good considering
that guy on the tird stand in the second violin section.

Where do I get netsend/receive? I’ll be happy to run a comparison. Is it
UB? One of my machines in Intel and the other is PPC. Both Max 4.6.

On 3/19/07 4:06 PM, "Jaime Oliver" wrote:

> besides that ocassional delay it works very well, i think you should
> try it… let me know which one works better for you.
>
> J
>
> On 3/19/07, Gary Lee Nelson wrote:
>> I just tried jit.net.send/recv and net.maxhole. Both are much worse than
>> udpsend/receive. The later at least keeps tempo. Just leaves note out now
>> and then. Should I try netsend/receive?
>>
>>
>>
>>
>> On 3/19/07 3:03 PM, "Olaf Matthes"

wrote:
>>
>>> Jaime Oliver wrote:
>>>> Hi Gary
>>>>
>>>> I get something similar. That is, every once in a while i receive a
>>>> message that my message sent through udp has been delayed 16 or 17
>>>> msec. I haven’t actually tested that they are not getting there, but I
>>>> have latencies i have to optimize all over the place, Olaf Mathes
>>>> wrote at some point that the object was complaining too much.
>>>
>>> Well, bur Gary was talking about udpsend and udpreceive and not
>>> netsend/netreceive.
>>>
>>> Olaf
>>>
>>>> Don’t know if this helps, but if anyone knows why this is happening
>>>> i’d love to get rid of those occasional 17 msecs…
>>>
>>> I oculd compile you a version that just doesn’t warn you but would block
>>> anyway if this makes you sleep any better. :-)
>>>
>>> Olaf
>>
>>
>> Cheers
>> Gary Lee Nelson
>> Oberlin College
>> http://www.timara.oberlin.edu/GaryLeeNelson
>>
>>
>>

Cheers
Gary Lee Nelson
Oberlin College
http://www.timara.oberlin.edu/GaryLeeNelson


March 19, 2007 | 9:01 pm

On 19 mars 07, at 21:51, Gary Lee Nelson wrote:

> I just did a benchmark on udpsend/receive. I am sending messages
> like these
>
> n 60 64 250 1 (for makenote in the receiver)
>
> Every 250 ms. I am measuring the interval between the arrival of
> messages
> and find +/- 5-6 ms deviation. Pretty good considering most
> conductors are
> happy with 50 ms. Still, it’s the dropped notes that are bothering
> me. I
> put counters on both ends and find that 4-5 notes are dropped out of a
> thousand sent sigly at 250 ms intervals. Again, pretty good
> considering
> that guy on the tird stand in the second violin section.

I’ve too remarks:
- if you want better timing, using an Ethernet cable will help a lot!
I know it’s sometimes difficult, but you’ll really get better
performances
- UDP may lost packets. Using TCP is much better when you need to be
sure that the data arrives (You may have a look to [mxj net.tcp.send]
and [mxj net.tcp.recv]).

Best,
ej


March 19, 2007 | 9:20 pm

On 19 Mar 2007, at 18:38, Gary Lee Nelson wrote:

> I am send them one per second and finding that 1 out of 20-30
> messages is
> dropped.

…which is exactly what it says on the tin. UDP does not guarantee
delivery (nor does it guarantee that the same transmitted packet will
not arrive more than once). More info at

http://www.faqs.org/rfcs/rfc768.html

I’ve never noticed UDP packets being dropped when doing OSC-over-UDP,
but then it’s either been cabled (through decent-quality switches),
or the OSC has been streaming sensor readings, in which case the
occasional dropped packet doesn’t matter.

If you want reliable transmission, use TCP.

– N.


March 19, 2007 | 9:49 pm

so udp is faster, but tcp is more reliable??

here is netsend

http://www.maxobjects.com/?PHPSESSID=6b60bdf5913b5f058c95a5372eb6db02&PHPSESSID=6b60bdf5913b5f058c95a5372eb6db02&request=netsend&operateur=AND&id_plateforme=0&Submit=OK

http://www.nullmedium.de/dev/netsend~/

best,

j

On 3/19/07, Nick Rothwell wrote:
>
> On 19 Mar 2007, at 18:38, Gary Lee Nelson wrote:
>
> > I am send them one per second and finding that 1 out of 20-30
> > messages is
> > dropped.
>
> …which is exactly what it says on the tin. UDP does not guarantee
> delivery (nor does it guarantee that the same transmitted packet will
> not arrive more than once). More info at
>
> http://www.faqs.org/rfcs/rfc768.html
>
> I’ve never noticed UDP packets being dropped when doing OSC-over-UDP,
> but then it’s either been cabled (through decent-quality switches),
> or the OSC has been streaming sensor readings, in which case the
> occasional dropped packet doesn’t matter.
>
> If you want reliable transmission, use TCP.
>
> — N.
>
>


March 19, 2007 | 9:51 pm

Gary Lee Nelson wrote:
> I just did a benchmark on udpsend/receive. I am sending messages like these
>
> n 60 64 250 1 (for makenote in the receiver)
>
> Every 250 ms. I am measuring the interval between the arrival of messages
> and find +/- 5-6 ms deviation. Pretty good considering most conductors are
> happy with 50 ms. Still, it’s the dropped notes that are bothering me. I
> put counters on both ends and find that 4-5 notes are dropped out of a
> thousand sent sigly at 250 ms intervals. Again, pretty good considering
> that guy on the tird stand in the second violin section.
>
> Where do I get netsend/receive?

http://www.akustische-kunst.org/maxmsp/ – But I have to agree with the
others that UDP is not 100% loss-free. Use TCP if you need 100% perfect
delivery. But the drawbackis that it will take longer to deliver the
data since there is more communication going on between receiver and sender.

Olaf


March 19, 2007 | 10:05 pm

>
> On 19 Mar 2007, at 18:38, Gary Lee Nelson wrote:
>
>> I am send them one per second and finding that 1 out of 20-30
>> messages is
>> dropped.
>
> …which is exactly what it says on the tin. UDP does not guarantee
> delivery (nor does it guarantee that the same transmitted packet will
> not arrive more than once). More info at
>
> http://www.faqs.org/rfcs/rfc768.html
>
> I’ve never noticed UDP packets being dropped when doing OSC-over-UDP,
> but then it’s either been cabled (through decent-quality switches),
> or the OSC has been streaming sensor readings, in which case the
> occasional dropped packet doesn’t matter.
I’m quite surprised by the bad results described here.
I recently built for a project a system of sensors sending information over
WiFi (11g) and sending UDP packets of 70 useful bytes every 8ms (not
counting header and checksum).
I programmed a 7-bit a counter on the microprocessor part that allows me to
monitor lost packets and I noticed a drop of usually less than 1 packet per
1000. Generally about only 1 per 2000, but some movements of the performer
might increase temporarily the percentage of dropped packets. This was at
about 30m distance in the concert hall, receiving with the built-in antenna
of my Alu G4 1.5 GHz.
Maybe there are too many Wifi networks around and you should change the
channel of your Wifi network?

And there are some cases where dropped packets may be an issue, even with
sensors: I do for example integrate the angular speed of gyroscopes to
compute the angular position…

Best,
Todor
_________________________________________
Web: http://compositeurs.be/Todoroff.html


March 19, 2007 | 10:54 pm

Thanks ej. Your two remarks were right on. I did have a look at [mxj
net.tcp.send] and [mxj net.tcp.recv] and I did get out my old ethernet hub.
After sending more than 5000 messages at 80 ms intervals, none was lost and
the biggest error I saw was +/- 6 ms which I am going to call "humanizing."

I have a hunch that it was the ethernet cables that did the trick but having
killed all of the alligators, I’m back to draining the swamp. Perhaps I’ll
test all of the other send/receive tools with the cables another time.

Thanks to everyone who helped.

On 3/19/07 5:01 PM, "Emmanuel Jourdan" wrote:

> On 19 mars 07, at 21:51, Gary Lee Nelson wrote:
>
>> I just did a benchmark on udpsend/receive. I am sending messages
>> like these
>>
>> n 60 64 250 1 (for makenote in the receiver)
>>
>> Every 250 ms. I am measuring the interval between the arrival of
>> messages
>> and find +/- 5-6 ms deviation. Pretty good considering most
>> conductors are
>> happy with 50 ms. Still, it’s the dropped notes that are bothering
>> me. I
>> put counters on both ends and find that 4-5 notes are dropped out of a
>> thousand sent sigly at 250 ms intervals. Again, pretty good
>> considering
>> that guy on the tird stand in the second violin section.
>
> I’ve too remarks:
> – if you want better timing, using an Ethernet cable will help a lot!
> I know it’s sometimes difficult, but you’ll really get better
> performances
> – UDP may lost packets. Using TCP is much better when you need to be
> sure that the data arrives (You may have a look to [mxj net.tcp.send]
> and [mxj net.tcp.recv]).
>
> Best,
> ej
>
>

Cheers
Gary Lee Nelson
Oberlin College
http://www.timara.oberlin.edu/GaryLeeNelson


March 19, 2007 | 11:26 pm

There’s always one more alligator. The mxj objects were sensitive to UI
objects. Moving sliders and the like increased the error to +/- 50%. Still
human but a bad drummer.

I went back to udpsend/receive and there are no lost messages after 10000+
at 80 ms. The error is also reduced to +/- 2-3. I even put in a
multislider with 256 controls and continually dragged back and forth on in.

An unexpected plus is that I can return to wireless just by turning the
airport on to send these messages then off to go back to ethernet. Doesn’t
take much to make an old man happy.

On 3/19/07 6:54 PM, "Gary Lee Nelson" wrote:

> Thanks ej. Your two remarks were right on. I did have a look at [mxj
> net.tcp.send] and [mxj net.tcp.recv] and I did get out my old ethernet hub.
> After sending more than 5000 messages at 80 ms intervals, none was lost and
> the biggest error I saw was +/- 6 ms which I am going to call "humanizing."
>
> I have a hunch that it was the ethernet cables that did the trick but having
> killed all of the alligators, I’m back to draining the swamp. Perhaps I’ll
> test all of the other send/receive tools with the cables another time.
>
> Thanks to everyone who helped.
>
> On 3/19/07 5:01 PM, "Emmanuel Jourdan" wrote:
>
>> On 19 mars 07, at 21:51, Gary Lee Nelson wrote:
>>
>>> I just did a benchmark on udpsend/receive. I am sending messages
>>> like these
>>>
>>> n 60 64 250 1 (for makenote in the receiver)
>>>
>>> Every 250 ms. I am measuring the interval between the arrival of
>>> messages
>>> and find +/- 5-6 ms deviation. Pretty good considering most
>>> conductors are
>>> happy with 50 ms. Still, it’s the dropped notes that are bothering
>>> me. I
>>> put counters on both ends and find that 4-5 notes are dropped out of a
>>> thousand sent sigly at 250 ms intervals. Again, pretty good
>>> considering
>>> that guy on the tird stand in the second violin section.
>>
>> I’ve too remarks:
>> – if you want better timing, using an Ethernet cable will help a lot!
>> I know it’s sometimes difficult, but you’ll really get better
>> performances
>> – UDP may lost packets. Using TCP is much better when you need to be
>> sure that the data arrives (You may have a look to [mxj net.tcp.send]
>> and [mxj net.tcp.recv]).
>>
>> Best,
>> ej
>>
>>
>
>
> Cheers
> Gary Lee Nelson
> Oberlin College
> http://www.timara.oberlin.edu/GaryLeeNelson
>
>

Cheers
Gary Lee Nelson
Oberlin College
http://www.timara.oberlin.edu/GaryLeeNelson


March 21, 2007 | 2:17 pm

Gary Lee Nelson schrieb:
> Thanks ej. Your two remarks were right on. I did have a look at [mxj
> net.tcp.send] and [mxj net.tcp.recv] and I did get out my old ethernet hub.
> After sending more than 5000 messages at 80 ms intervals, none was lost and
> the biggest error I saw was +/- 6 ms which I am going to call "humanizing."

-6 ms I’d call "supernatural". A message arriving before it got send…

I guess you refer to the jitter, but whats the latency you get with your
setup?

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


March 21, 2007 | 5:22 pm

Exactly right. It’s +/- 2-3 ms jitter but I didn’t want to make people
think I was talking about video. Yes, latency is a different thing. Now
that it is working, I am measuring entirely by ear and there doesn’t seem to
be a latency issue using the ethernet port.

I have a master Mac running some MSP pitch tracking of a speaking voice. The
extracted pitches are sent in what is essentially midi via udp to two other
Macs. Those macs are playing orchestral timbres via Garritan vst~ in MSP.
The output of those two are routed through a mixer back into the first mac
via input channels of a Motu 828. The audio from all machines is mixed,
passed through a reverb and recorded to use as a sound track for a film.
BTW, the first mac is also playing the film to verify synchronization.

Yes, yes, I know. I am passing through the analog world and the sound is
too, too awful. Actually there no lack of quality in the sound, again to my
ears. If someone can suggest how to transmit multi-channel audio over
firewire or ethernet I would be glad to go all digital. In the meantime, I
try to use content to mask deficiencies in audio quality. :)

Cheers
Gary Lee Nelson
Oberlin College
http://www.timara.oberlin.edu/GaryLeeNelson

On 3/21/07 10:17 AM, "Stefan Tiedje" wrote:

> Gary Lee Nelson schrieb:
>> Thanks ej. Your two remarks were right on. I did have a look at [mxj
>> net.tcp.send] and [mxj net.tcp.recv] and I did get out my old ethernet hub.
>> After sending more than 5000 messages at 80 ms intervals, none was lost and
>> the biggest error I saw was +/- 6 ms which I am going to call "humanizing."
>
> -6 ms I’d call "supernatural". A message arriving before it got send…
>
> I guess you refer to the jitter, but whats the latency you get with your
> setup?
>
> Stefan


March 22, 2007 | 11:06 am

Gary Lee Nelson schrieb:
> If someone can suggest how to transmit multi-channel audio over
> firewire or ethernet I would be glad to go all digital.

Another alternative is to use adat digital connections with appropriate
interfaces…

But for other reasons I’d like to know if there is some kind of usable
protocol to send multi channel audio over gigabit ethernet cable as
well. The speed should be sufficient for a lot of channels, but what
about latency, assuming no other internet traffic is going across…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


March 22, 2007 | 11:20 am

Stefan Tiedje wrote:
> Gary Lee Nelson schrieb:
>> If someone can suggest how to transmit multi-channel audio over
>> firewire or ethernet I would be glad to go all digital.
>
> Another alternative is to use adat digital connections with appropriate
> interfaces…
>
> But for other reasons I’d like to know if there is some kind of usable
> protocol to send multi channel audio over gigabit ethernet cable as
> well. The speed should be sufficient for a lot of channels, but what
> about latency, assuming no other internet traffic is going across…

Bandwidth is not a problem, even over 100Mbit you can have lots of
channels. But (one of my standard answers copied from another thread):

"But the problems are the same as audio over ethernet: clock skew.
In order to get it working correctly the receiving machine would need to
sync it’s audo hardware to a clock derived from the incoming signal.
That’s impossible with almost all the hardware thers is… so dirty
tricks in software are needed which will deal with dropouts, buffer
overflows…. And all these software fixes introduce more latency
because they need additional buffers."

With using ADAT you would slave the receiver to the sender clock. With
audio over ethernet you can’t.
If we ignore these problems latency is about the ping time plus a few
samples.

Olaf


March 22, 2007 | 1:36 pm

I have a Motu 828 and a Motu 828MKII each connected to a different machine.
Can I link them via their ADAT connections?

On 3/22/07 7:20 AM, "Olaf Matthes"

wrote:

> Stefan Tiedje wrote:
>> Gary Lee Nelson schrieb:
>>> If someone can suggest how to transmit multi-channel audio over
>>> firewire or ethernet I would be glad to go all digital.
>>
>> Another alternative is to use adat digital connections with appropriate
>> interfaces…
>>
>> But for other reasons I’d like to know if there is some kind of usable
>> protocol to send multi channel audio over gigabit ethernet cable as
>> well. The speed should be sufficient for a lot of channels, but what
>> about latency, assuming no other internet traffic is going across…
>
> Bandwidth is not a problem, even over 100Mbit you can have lots of
> channels. But (one of my standard answers copied from another thread):
>
> "But the problems are the same as audio over ethernet: clock skew.
> In order to get it working correctly the receiving machine would need to
> sync it’s audo hardware to a clock derived from the incoming signal.
> That’s impossible with almost all the hardware thers is… so dirty
> tricks in software are needed which will deal with dropouts, buffer
> overflows…. And all these software fixes introduce more latency
> because they need additional buffers."
>
> With using ADAT you would slave the receiver to the sender clock. With
> audio over ethernet you can’t.
> If we ignore these problems latency is about the ping time plus a few
> samples.
>
> Olaf

Cheers
Gary Lee Nelson
Oberlin College
http://www.timara.oberlin.edu/GaryLeeNelson


March 22, 2007 | 9:40 pm

On 22-mars-07, at 14:36, Gary Lee Nelson wrote:

> I have a Motu 828 and a Motu 828MKII each connected to a different
> machine.
> Can I link them via their ADAT connections?
>

Of course, just make sure they are in sync.

p


March 23, 2007 | 8:51 pm

Olaf Matthes schrieb:
> In order to get it working correctly the receiving machine would need to
> sync it’s audo hardware to a clock derived from the incoming signal.

Just another cable for the good old house clock…

Or someone has to built a little ethernet to digital clock converter,
which then would sync the hardware…

Which interfaces do allow software sync? If most don’t, it would be
interesting to know which do…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com


Viewing 22 posts - 1 through 22 (of 22 total)