Re: pass-thru using audio queues
Re: pass-thru using audio queues
- Subject: Re: pass-thru using audio queues
- From: William Stewart <email@hidden>
- Date: Thu, 3 Dec 2009 19:20:24 -0800
On Dec 3, 2009, at 6:58 PM, Aaron B. wrote:
On Thu, Dec 3, 2009 at 9:07 PM, Paul Davis
<email@hidden> wrote:
On Thu, Dec 3, 2009 at 9:01 PM, Aaron B. <email@hidden> wrote:
Hi,
I asked about doing pass-thru using Audio Queues earlier, and there
were no responses so I assumed it must be easy. I've got it working
at a latency of about 0.3 seconds, using the following technique:
the
input callback writes data to a ring of 6 buffers and the output
callback reads data from the ring of buffers, and they use
hand-over-hand locking with POSIX mutexes to follow along the ring
of
buffers.
why not just use a lock-free single-reader/single-writer ringbuffer?
Locking vs. lock-free seemed like they would be equally easy to code
up, and I thought that blocking on locks would automatically throttle
the timing of the producer/consumer threads if one temporarily got too
far ahead or behind, whereas with lock-free I would have to drop
samples or insert silence manually. On the plus side, if I correctly
add/drop samples in a lock-free design, it should also alleviate my
start-up timing concerns.
You could use the same thread for both the input and output queue,
then you don't need locks at all
(you just pass in the same run loop to both constructors)
(Unfortunately, the
pthread_mutex_trylock function isn't any help because it seems to
often give "false negatives," saying it can't acquire a lock even
when
no one else is holding it.)
that suggests either a serious implementation problem in the OS X
pthreads library or a misunderstanding/design flaw in your code.
ardour uses pthread_mutex_trylock() a great deal, and i can't say
that
i've specifically tested its behaviour on OS X, but have had no
reports on any issues that would relate this kind of misbehaviour on
its part.
I only observed this behavior from within the Audio Queue callbacks.
It wouldn't surprise me if pthread_mutex_trylock() works just fine in
other contexts.
I am skeptical - we just pthreads all over the place and have not had
these issues. You might want to look at the way we support these with
the CAGuard and CAMutex classes - they provide Try and Lock (build on
pthread) and these work everywhere we've tried them
Bill
_______________________________________________
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