Re: Detecting dropouts?
Re: Detecting dropouts?
- Subject: Re: Detecting dropouts?
- From: Jeff Moore <email@hidden>
- Date: Wed, 27 Mar 2002 12:40:33 -0800
on 3/25/02 9:03 AM, Jim Dolan <email@hidden> wrote:
>
I have a method that keeps track of the sample position from IOProc to
>
IOproc callbacks to ensure that there is no dropouts.
>
>
For example:
>
During the input IOProc I store the inInputTime.mSampleTime value. During
>
the next IOproc I add the buffer size in samples (adjusted for interleaving)
>
to the stored value. This should give me the new inInputTime.mSampleTime
>
value. In general this calculation seems accurate and works much of the
>
time. If the calulation does not match, meaning the (old_mSampleTime +
>
buffersize > current_mSampleTime ) I am assuming there is a gap in the
>
stream. Is this a valid assumption? The kAudioDeviceProcessorOverload is
>
never triggered. If my assumtion is correct what can I do to avoid this
>
situation? If I am not calculating correctly - how can I tell?
>
>
Can I safely assume that each time the record IOProc is called that samples
>
have not been dropped evn if the sampletimes do not match up?
The sample numbers should in theory be contiguous for as long as the device
is running. In the case that they are not, it should indeed be interpreted
as a gap. There isn't anything wrong with your logic. I am a bit puzzled by
the fact that kAudioDeviceProcessorOverload isn't also firing (sounds like
a bug). Can you describe the situation on the machine when this is going on?
And how far off are things?
>
The current buffer size I am using is 1024 bytes - Would making this
>
smaller or larger help? I need to ensure that the sample stream is pristine
>
ie: NO LOST SAMPLES on record or playback!!!!!!!!!
1024 bytes is on the small side (256 frames of mono 32 bit floats, the
default is 512 frames), but not unreasonably small for 44.1kHz sample rates
(may be pushing things for 96kHz and higher though). Increasing your buffer
size will make the period of the IO thread longer which will leave more time
for the rest of the system to do it's thing. It can't hurt things to make
your buffer's larger.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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.