Re: old mtcoreaudio code doesn't work now
Re: old mtcoreaudio code doesn't work now
- Subject: Re: old mtcoreaudio code doesn't work now
- From: Michael Thornburgh <email@hidden>
- Date: Sun, 6 Jan 2008 16:40:37 -0800
On Jan 6, 2008, at 4:08 PM, dudley ackerman wrote:
On Jan 6, 2008, at 12:41 PM, Michael Thornburgh wrote:
well, i don't know exactly how you're using your inConverter and
outConverter. are you doing live play-through, recording and
playing out immediately? or are you recording from the input
device to a buffer or file or something with [self sampleRate]
samples per second, and then later playing out that buffer to the
output device?
if you're doing live play-through, then you have too many
MTConversionBuffers. you'd just need one for the samples to flow
through from input to output.
i am not doing playthrough. i am receiving the record in a buffer
that i hold and, at the user's request, playback.
i didn't actually w rite this code - it is inherited. but it does
work on tiger.
so i am confused why there would be 2 converters for recording, and,
then, 2 more created for playback.
regardless of how you're hooking up these conversion buffers,
judging only from the names, i don't think you're setting them up
correctly. based on the names, it seems to me they should be
configured:
inConverter: source side: from inputDevice; destination side: to
outputDevice (for live play-through) or whatever "self" is (for
recording and later playback).
outConverter: source side: from inputDevice (for live play-
through) or whatever "self" is (for recording and later playback);
destination side: to outputDevice.
the buffer sizes are probably also too small. they need to be big
enough to hold *at least* one IOProc/IOTarget callback buffer's
worth of samples, or you'll over- or under-flow the buffer during
the input or output side's action. you want the buffers to be
small to keep latency down, but IOProc dispatch jitter will cause
over- or under-flow unless there's some slop. plus you have to be
reading out samples fast enough to keep the input from overflowing,
or feed samples in fast enough to keep the output from overflowing,
if either end isn't real-time (like, in the record to or play back
from a buffer or file or something case).
hmm. so you don't think the code that computes the buffer size is
good?
ok - i cleaned that all up so only 1 converter is created on record
and 1 on playback.
and i cleaned up the names, so buffers and converters for record are
named 'in' and 'out' for playback.
given that you're recording to (and later playing from) a non-realtime
buffer, i'd suggest making the MTConversionBuffers large-ish, like a
second or so, to give plenty of time for the non-realtime consumer
(record) or producer (playout) long enough to get their work done in
the presence of realtime work also happening (the actual audio threads).
finally: be sure you're using MTCoreAudio 1.3.2 (the actual latest
rel ase), or later (if you're reading this in the far future), or
MTConversionBuffers just won't work on Leopard
definitely using 1.3.2
HTH.
i appreciate your response.
but i want to emphasize that the outputDevice is failing to be
opened which is a problem prior to any buffer issues.
this didn't happen when i was using mtcoreaudio as a framework --
only, now, when i include the files directly in my project. what can
i look for to figure this issue out? or what info could i gather
that would help someone help me?
what exactly do you mean by "failing to be opened"? do you mean
outputDevice is nil? or it's non-nil, but the device has no output
streams/channels? or it does, but you can't start any IO on it?
i don't remember any special secret compile-time settings that would
affect the behavior of any of the classes at load time. i don't see
any +load methods at all, nor any +initialize ones that would cause
only some audio devices to not work anymore. so i don't see a reason
why framework vs non-framework would affect anything.
remember to call
[MTCoreAudioDevice attachNotificationsToThisThread];
in your main() before starting NSApplicationMain(). that's probably
not your problem, but it's important anyway.
-mike
_______________________________________________
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