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 10:48:58 +0100
------------------------------
Message: 9
Date: Tue, 17 Mar 2009 11:12:33 -0700
From: Jeff Moore <email@hidden>
Subject: Re: Coreaudio-api Digest, Vol 6, Issue 134
To: CoreAudio API <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes
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.
At any rate, I think your best bet is to also follow up with one of
the more network and/or kernel focused lists (darwin-dev might be a
good place) or to get in touch with our Developer Support folks.
Thanks I'll do that.
Now the one million dollar question ((-: how does not AuNetSend/
AuNetReceive do this kind of things? I guess that by additional
buffering, the latencies can be "smoothed" in some way...
Thanks.
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