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: dudley ackerman <email@hidden>
- Date: Sun, 6 Jan 2008 16:08:25 -0800
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.
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?
-mike
robert
_______________________________________________
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