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:24:42 +0100
------------------------------
Message: 2
Date: Tue, 17 Mar 2009 14:10:34 -0700
From: Jens Alfke <email@hidden>
Subject: Re: Coreaudio-api Digest, Vol 6, Issue 134
To: Jeff Moore <email@hidden>
Cc: CoreAudio API <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset="windows-1252"
On Mar 17, 2009, at 11:12 AM, Jeff Moore wrote:
From that backtrace, it seems like there is a lot of sleeping going
on. Some of it looks lock related, but some of it also looks like
waiting. I don't know enough about the network stack to say if this
would be considered a bug or not, but it never hurts to file one and
find out.
Yeah, the fact that the socket is not set to non-blocking makes me
suspicious that the read call is actually waiting for a packet that
hasn't arrived yet.
Or not handled at the right time by the kernel socket code (so then
looks like a "priority inversion" or kernel looking issue).
Have you tried making the socket nonblocking?
Not really since we use the packet as the way to synchronize the
audio cycle on the slave machine. But I guess using "select/poll +
read" would not show a different (and better) behaviour if something
wrong happens in the kernel.
I assume that you're doing the networking this way, with no buffering
at all, to get the minimum possible latency?
Yes this is the point, we want minimal latency (well it is even
possible to have a master/slave model where the audio data goes
master ==> slave ==> master in the *same* cycle, so without any
additional latency, but that makes sense only with a fast network,
like gigabit).
Normally you'd be reading
packets from a separate thread and pushing the data into a queue that
the audio thread reads from.
Well "normally" is not what we want to do. We want lowest possible
latency... and correct behaviour... as other POSIX system like Linux
or Solaris can do without comparable problems. So it looks like a
specific OSX isssue AFAICS.
Regards.
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