Udpsend and udpreceive dropping messages

Mar 19, 2007 at 6:38pm

Udpsend and udpreceive dropping messages

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

#30915
Mar 19, 2007 at 6:51pm

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
>
>
>

#99535
Mar 19, 2007 at 7:03pm

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

#99536
Mar 19, 2007 at 7:20pm

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
>

#99537
Mar 19, 2007 at 7:53pm

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

#99538
Mar 19, 2007 at 7:59pm

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

>

#99539
Mar 19, 2007 at 8:06pm

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
>
>
>

#99540
Mar 19, 2007 at 8:51pm

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

#99541
Mar 19, 2007 at 9:01pm

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

#99542
Mar 19, 2007 at 9:20pm

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.

#99543
Mar 19, 2007 at 9:49pm

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.
>
>

#99544
Mar 19, 2007 at 9:51pm

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

#99545
Mar 19, 2007 at 10:05pm

>
> 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

#99546
Mar 19, 2007 at 10:54pm

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

#99547
Mar 19, 2007 at 11:26pm

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

#99548
Mar 21, 2007 at 2:17pm

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

#99549
Mar 21, 2007 at 5:22pm

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

#99550
Mar 22, 2007 at 11:06am

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

#99551
Mar 22, 2007 at 11:20am

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

#99552
Mar 22, 2007 at 1:36pm

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

#99553
Mar 22, 2007 at 9:40pm

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

#99554
Mar 23, 2007 at 8:51pm

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

#99555

You must be logged in to reply to this topic.