Re: Sync question about CoreAudio and DCL program callback
Re: Sync question about CoreAudio and DCL program callback
- Subject: Re: Sync question about CoreAudio and DCL program callback
- From: Jeff Moore <email@hidden>
- Date: Mon, 19 Jan 2009 18:13:48 -0800
On Jan 19, 2009, at 5:42 PM, David Tan wrote:
Hi Jeff,
So glad to get kind reply from you again!
>> The IOAudio family already locks around accessing the buffers. In
fact, IOAudioEngine::clipOutputSamples() is called while holding
those locks.
>> So you may not need to add any additional locking, provided you
set up your re-entrancy to take advantage of that.
Do you mean that mixbuf and samplebuf in clipOutputSamples()
parameter list are protected by IOAudio’s own lock mechanism?
Yes. If you go grab the sources from Darwin, you can see it. (Even an
old version will show this since this area of IOAudio hasn't changed
much over the years.)
Sorry for not describing my issue clearly. Actually theirs is a
mediate buffer I’m using for transferring audio data between mixbuf
and DCL program output buffer. In clipOutputSamples() I will copy
audio data from IOAudioFamily to this mediate buffer. And in DCL
program callback I’ll copy audio data from this mediate buffer to
DCL program output buffer. As clipOutputSamples() and DCL program
callback are not running in the same thread, do you think it’s
necessary to add access protection to this mediate buffer? Thanks a
lot!
First off, that seems like a lot of buffer copies to get the data into
the buffer the DMA reads from. That seems kind of inefficient to me,
but I don't know enough about your driver (or FireWire for that
matter) to know if both copies are really required. One thing to
explore is to see if you can't just copy from the IOAudio buffer
directly into the buffer for the DCL program.
As for whether your scenario is going to need more locks, I'd say no.
This is not to say that you don't need any thread synchronization for
this. This model sounds like you have a single producer
(clipOutputSamples()) and a single consumer (the DCL callback). There
exist ways to do this so that you don't need to lock anything.
FWIW, lock-less data structures for this sort of purpose have been
discussed on this list a few times in the past.
Sincerely yours,
David Tan
Software Engineer
Dextrys Co., Ltd.
From: coreaudio-api-bounces+david.tan=email@hidden [mailto:coreaudio-api-bounces+david.tan=email@hidden
] On Behalf Of Jeff Moore
Sent: 2009年1月20日 1:54
To: CoreAudio-API Mailing List Apple
Cc: Apple Firewire Mailing List
Subject: Re: Sync question about CoreAudio and DCL program callback
It is almost certainly the case that
IOAudioEngine::clipOutputSamples() will not run on the same thread
or work loop as your DCL callbacks. The reason why is that
IOAudioEngine::clipOutputSamples() is called from the IOAudio kernel
trap which executes on the HAL's IO thread.
The IOAudio family already locks around accessing the buffers. In
fact, IOAudioEngine::clipOutputSamples() is called while holding
those locks. So you may not need to add any additional locking,
provided you set up your re-entrancy to take advantage of that.
On Jan 19, 2009, at 1:02 AM, David Tan wrote:
I’m working on a FireWire audio driver and got a critical question
about the sync of IOAudioEngine::clipOutputSamples() and DCL program
Callback.
What I want to do is to copy audio data from CoreAudio buffer to the
output buffer of DCL program. But I’m not sure if
clipOutputSamples() and DCL program callback will run in the same
workloop.
Because if they run in different threads, I have to put a semaphore
or something like this to protect the buffer access from two
threads, One of which is writing in clipOutputSamples(), and the
other is reading in DCL program callback. And if we have to do this,
I wonder if there’s any good way you can recommend.
Any experience of advice will be much appreciated! Thanks a lot!
--
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