Re: pass-thru using audio queues
Re: pass-thru using audio queues
- Subject: Re: pass-thru using audio queues
- From: "Aaron B." <email@hidden>
- Date: Thu, 3 Dec 2009 21:58:37 -0500
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.
>> (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.
- 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