Re: render callback timing
Re: render callback timing
- Subject: Re: render callback timing
- From: Jeff Moore <email@hidden>
- Date: Thu, 4 Mar 2004 17:33:53 -0800
On Mar 4, 2004, at 4:01 PM, Josh Anon wrote:
Hi,
I'm trying to port a library for sync sound (to video) to the Mac.
I've got a ring buffer setup that I write into, and in the core audio
render callback, I read from there and copy it into the output buffer.
In my configure method, I set the audio device buffer size to
(UInt32)((10.0/1000.0 * rate * _bytesPerSample) + .5); to get 10ms of
audio. I also keep a listener for if the buffer size changes to set
it back to that.
Hopefully you are prepared to get an error when you do this since some
devices require buffers to be a power of 2 or some other even number.
In the callback, I also store the next play time in nanoseconds
(AudioConvertHostTimeToNanos) and, when asked, add that to device +
stream latency in nanos and return it as the next play time.
I'm not sure I follow what you are trying to accomplish here. What time
stamps are you using and for what purpose?
However, I've got some weird things going on. If I keep track of how
frequently the render callback is called, I would expect it to vary as
the device buffer size varies. However, it's always about 2494338ns,
or 1/2 as often as I would expect.
My guess is that you aren't setting the IO buffer size to be what you
think. 2494338ns is ~2.5 milliseconds. If your IOProc is being called
that often, it means you set the buffer size to be a quarter of the 10
milliseconds you thought you were setting it to.
It sounds like you are using kAudioDeviceBufferSize to set the IO
buffer size in terms of bytes. This is not going to work quite like you
expect for devices that have multiple streams. You really ought to be
setting the buffer size using kAudioDeviceBufferFrameSize and set the
buffer size in terms of sample frames.
This might also be part of another problem--I have a test app which
gets the current time, adds a small increment, plays silence until
then, and then gets the next play time. On Linux with OSS, this gives
< 2 audio frame differences consistently, but with CoreAudio, it
varies from 50 - 2000 frames.
It sure sounds like you are misusing the time stamps the HAL is
providing, or at least don't understand what they mean and how
kAudioDevicePropertyLatency factors into things. I could probably help
you out if you give me some more detail about what you are doing using
the HAL's terminology (so I can relate).
--
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.