Re: Socket recv behaviour in real-time context
Re: Socket recv behaviour in real-time context
- Subject: Re: Socket recv behaviour in real-time context
- From: Stéphane Letz <email@hidden>
- Date: Wed, 18 Mar 2009 20:13:56 +0100
Message: 1
Date: Tue, 17 Mar 2009 20:08:42 +0000
From: Ian Kemmish <email@hidden>
Subject: Re: Socket recv behaviour in real-time context
To: email@hidden
Message-ID: <email@hidden>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
On 16 Mar 2009, at 23:11, St?phane Letz <email@hidden> wrote:
No, the socket is in blocking mode. The "master" is synchronized on
it's real audio callback and send/recv audio paket to the slave. The
idea is that the reception of the audio packet trigger the audio
cycle on the "slave" machine.
It's 20 years since I did any networking, but UDP always used to be an
unreliable protocol. And in those days it was so literally true that
one avoided using UDP:-)
Could it be the case that the packet (or packets) is simply being
dropped, rather than delayed? That would be inconvenient, but strictly
speaking not a bug.
If you're stuffing serial numbers into your packets, this would be a
relatively easy thing to check....
Our packets have a serial number yes, and none are dropped/lost in
this specific test. Only "delayed".... (and again only when loading
the machine). And the exact same "POSIX" code works reliably on Linux
or Solaris (yes, we know that we can have occasional lost packets in
UDP, but this is not the point of the initial post).
Stephane Letz
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden