pass-thru using audio queues
pass-thru using audio queues
- Subject: pass-thru using audio queues
- From: "Aaron B." <email@hidden>
- Date: Thu, 3 Dec 2009 21:01:47 -0500
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.
When the buffer sizes are big enough, there is no lock contention and
everything is fine. However, when the buffer sizes are smaller and
one callback tries to grab a lock held by the other, the whole program
deadlocks. Why is this? Are POSIX mutexes not safe to use in Audio
Queue callbacks? I mean, I know an over-/underflow situation is going
to cause some kind of anomaly, but I want to detect it and handle it
rather than having a complete deadlock. (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.)
My other issue is this: when the input and output callback share a
ring of buffers, the safest situation (furthest from over-/underflow)
is when they are working at opposite ends of the ring. I initialize
the data structures so that this is the configuration before calling
AudioQueueStart. However, the time between calling AudioQueueStart
and the time each queue really gets started seems a little variable.
If I had a way of coordinating the two queues to *really* start at the
same time, it seems the safest latency could be much lower.
(Something tells me that doing pass-thru audio shouldn't be quite this
hard, which is why I probed with a question before trying it this
way.)
- Aaron
_______________________________________________
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