MPNotifyQueue takes 500,000 nsec (worst case)
MPNotifyQueue takes 500,000 nsec (worst case)
- Subject: MPNotifyQueue takes 500,000 nsec (worst case)
- From: EJ Campbell <email@hidden>
- Date: Mon, 21 Oct 2002 21:43:12 -0700
How is everyone here communicating with other threads from within your
IOAudioProc? I've tried using both a MPQueue and a semaphore to
facilitate communication between threads, and they both result in the
same behaviour: occasionally the synchronization primitive takes an
extremely long time to complete. The problem is described in detail
below and was originally posted on the multiprocessing mailing list
without garnering a reply:
I'm having trouble reliably calling MPNotifyQueue from inside a
realtime thread on Mac OS 10.2. I'm using the queue to notify an
MPThread (operating at a lower priority) that a buffer of incoming
audio data is ready for processing.
I'm using the Sound Manager API, specifically SPBRecord with a Sound
Input Completion Proc, to record audio. My completion procedure is
called from within a realtime thread whenever a buffer of audio data is
ready for processing. In my completion procedure, I call MPNotifyQueue
to let my sound processing thread know that a buffer of data is ready
to be processed.
Most of the time everything works perfectly. However, occasionally, I
loose packets of audio. To track down the problem, I profiled my entire
input completion procedure. What I found was that occasionally the call
to MPNotifyQueue (or MPSignalSemaphore) takes a VERY long time to
complete. Normally the call takes approximately 1,500 nanoseconds.
However, during times when I loose audio packets, this call can take
upwards of 500,000 nanoseconds, which unacceptable when inside of a
record completion procedure.
Does anyone have any clues as to what is going on? My queue has plenty
of room reserved to it by MPSetQueueReserve(), and there's no more than
one or two items in the queue at any time. I can't think of anything
else that is relevant. Does it matter that I'm still using SPBRecord?
Why would that affect the time it takes MPNotifyQueue to complete. What
seems to be happening is that the synchronization primitives are
causing the realtime thread that the completion proc is run in to go to
sleep and the processing thread to wake up and begin processing. This
seems like it's the wrong behavior since a realtime thread should never
be preempted, or at the very least, not preempted by a lower priority
thread.
I'd be extremely appreciative of any suggestions as to what I can do
to make MPNotifyQueue more reliable. The only alternative I see is to
completely decouple my processing thread from my completion proc.
Instead of using a semaphore or queue to notify the processing thread
that a buffer of data is ready, I could rely on the fact that data
arrives in a regular fashion, and use a timer that periodically wakes
the processing thread whenever data should be ready for it to process.
But this is not the right way to do it, and I'd like to not have to
rely on any polling whatsoever.
Thanks,
EJ
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.