Re: Virtual audio device glitches
Re: Virtual audio device glitches
- Subject: Re: Virtual audio device glitches
- From: Robert Bielik <email@hidden>
- Date: Fri, 15 Oct 2010 09:01:24 +0200
Jeff Moore skrev 2010-10-14 22:16:
No. That's not a bug. The calculation does what it says it does.
Consider that the sample time that the block one less than the current time is going to cover is:
start: (mCurrentBlock - 1) * mBlockSize
end: ((mCurrentBlock - 1) * mBlockSize) + (mBlockSize - 1)
Simplifying the expression for the ending sample gives you:
end: (mCurrentBlock * mBlockSize) - mBlockSize + mBlockSize - 1
end: (mCurrentBlock * mBlockSize) - 1
So, this function is returning the number of the last sample in the block one less than the current one. The 'if' statement protects the calculation from rolling over when one is subtracted from zero in an unsigned calculation when the IO engine is starting up.
I understand the arithmetic, but then the comment is faulty: "one full block behind". The implementation is thus 1 frame behind :)
Also shouldn't it then be:
const UInt32 numFramesPerBuffer = getNumSampleFramesPerBuffer();
theAnswer = (mCurrentBlock * mBlockSize + numFramesPerBuffer - 1) % numFramesPerBuffer;
since mCurrentBlock can be zero not only at the start of the engine, but at each buffer wrap ?
Well, anyways... I still have the glitch problem, and now its even worse (meaning glitching from the start, not even having to
do anything extra), WITH disabling the erase head.
My architecture in short: A user mode application pulls data from the device via a IOUserClient API call with the same no of frames
that the engine is set to. I pass AudioTimeStamp.mHostTime in the call to provide timestamps derived from the output device
the UM app is sending audio to (i.e. I call takeTimeStamp in that API call). Thus, I feel that the timestamps should be pretty stable, and debugging the time diff during buffer wraps seems to confirm that. Between clipOutputSamples and the IOUserClient API I have a ring buffer which just pipes bytes.
I'm fairly sure the ring buffer is OK, so how/where could those pops/clicks be introduced ?
Regards
/Rob
_______________________________________________
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