Re: Two AUHALs, one ring buffer, and one AU filter. But no sound.
Re: Two AUHALs, one ring buffer, and one AU filter. But no sound.
- Subject: Re: Two AUHALs, one ring buffer, and one AU filter. But no sound.
- From: Doug Wyatt <email@hidden>
- Date: Thu, 1 Jul 2004 16:44:45 -0700
On Jul 1, 2004, at 16:27, Robert Grant wrote:
Hey John,
Well in my head I'm thinking that if the ring buffer is getting filled
at a different rate than being emptied then the read and write heads
will eventually meet (overflow or underflow) and thus cause you to
make a decision (drop or duplicate a buffer) - that decision will
cause a subtle audio glitch. Of course the closer they are in sync the
longer it'll take for that to happen.
At least that's what I think will happen - I'm hiding from the problem
currently :-)
Robert.
Robert,
I've actually witnessed what you're thinking, so you're not just
imagining things :-)
I was using AudioThru (in the SDK) between built-in and a USB device.
Even a difference of 1 sample per second will result in failure before
long -- very quickly if output is faster, longer if input is faster
(though latency will be steadily increasing before things fail).
Doug
On Jul 1, 2004, at 7:19 PM, john wrote:
Hi Chilton,
What Robert suggested is good. Though I'm not sure why he says you'll
eventually get audio glitches (can you answer Robert?).
I use a similar method - using MTCoreAudio's MTByteBuffer I grab data
from the input proc, do stuff with it, then when the AudioUnit output
calls back I just return to it the amount of data it wants. I never
have any audio glitches (at least that I notice).
-- John
Hi Chilton,
What you're trying to do is not impossible. You can pass the audio
from the input device (the iMic) through your buffer to the output
device. The syncing issue is that the two devices may be running at
slightly different actual sample rates - even though they're both
set to 44.1 kHz (for example) - meaning that you're eventually going
to get subtle audio glitches.
It sounds like you need to build things bit by bit:
Get input working with your render proc
Then start putting it in the ring buffer.
Then start pulling from the buffer using the render callback from
your Output Unit.
Then insert your filter.
Trying to do it all in one go seems to be adding confusion...?
Best,
Robert.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.