RE: Detecting dropouts?
RE: Detecting dropouts?
- Subject: RE: Detecting dropouts?
- From: Jim Dolan <email@hidden>
- Date: Thu, 28 Mar 2002 10:28:44 -0500
Thanks -
I was mistaken on the buffer size - I actually increased them a while back
to 4096 bytes.
When there is a gap , the sample position is off anywhere from 500 to 2000
samples. The system does not really need to do anthing stressfull to get
the behavior. I have a passthrough mode in my app that just starts up the
IOProcs and copies the samples from input to an intermediate buffer then to
the output side.
Jimmy D.
-----Original Message-----
From: Jeff Moore [
mailto:email@hidden]
Sent: Wednesday, March 27, 2002 3:41 PM
To: CoreAudio API
Subject: Re: Detecting dropouts?
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.
_______________________________________________
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.