• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Socket recv behaviour in real-time context
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Socket recv behaviour in real-time context


  • Subject: Re: Socket recv behaviour in real-time context
  • From: Jeff Moore <email@hidden>
  • Date: Sat, 14 Mar 2009 17:45:46 -0700

I don't really know a whole lot about sockets or our network stack. But, your description of the problem sounds like there could be a priority inversion problem on your slave machine. Even though the thread you have servicing the socket is a real time thread, I'd bet good money that the thread in the kernel that feeds the socket is not. This means that the more activity you have in your real time threads (including the HAL's IO thread or any MIDI threads) will cause scheduling latency for lower priority threads.

That said, 50 milliseconds seems completely crazy. You'd have to have an awful lot of real time threads doing work to get that kind of scheduling latency. Have you gotten any kernel traces?

On Mar 13, 2009, at 10:30 AM, Stéphane Letz wrote:

We are using UDP sockets to transmit audio in real-time between 2 machines. Basically the "master" machine is synchronized on the audio interrupt and send/recv audio packets on the "slave" machine. The "slave" machine is synchronized on incoming packets (that is waiting for an incoming packet on the socket to start it's audio cycle). The "slave" machine reception thread is set-up in real-time mode (using thread_policy_set /THREAD_TIME_CONSTRAINT_POLICY kind of API).

It works quite reliably until we start to load the slave machine (like starting a big compilation). In this case the RT slave thread does not "wake up" the the right time, and we have quite big latencies (up to 50 millisecond latency measured on a MacPro Intel 4 cores 10.5.6 when the audio cycle is supposed to be 5 millisecond). More precisely it seems the socket recv operation blocks a lot of time.

We configure the socket with SO_SNDBUF/SO_RCVBUF and possibly SO_RCVTIMEO kind of options. The same code works without problem on Linux.

Are they special socket options to add in this case on OSX? Is this a known problem for sockets on OSX?



--

Jeff Moore
Core Audio
Apple


_______________________________________________ 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
References: 
 >Socket recv behaviour in real-time context (From: Stéphane Letz <email@hidden>)

  • Prev by Date: Re: Confused about data returned from an FFT for a AU
  • Next by Date: Re: Socket recv behaviour in real-time context
  • Previous by thread: Socket recv behaviour in real-time context
  • Next by thread: Re: Socket recv behaviour in real-time context
  • Index(es):
    • Date
    • Thread