Re: small buffer size
Re: small buffer size
- Subject: Re: small buffer size
- From: David Duncan <email@hidden>
- Date: Mon, 17 May 2004 07:12:23 -0400
On May 17, 2004, at 03:31 AM, Mark's Studio wrote:
The AU is visualizing the audio (no change to the audio), and i use the
rate of the callback to update the display so i need a very small
buffer for it to look right.
Do you have to display every sample? At 44.1Khz 32 samples are going to
be current for less than a millisecond, which no monitor in existence
can even keep up with. At the bare minimum a 120hz monitor would be
able to respond to a visual change only every 367.5 samples
(44100/120). This disparity gets worse as the sample rate increases and
the monitor refresh rate decreases.
So if i have to use the size provided by the host, I would like to know
how i can split it up.
Just take 32 samples at a time and feed it to a buffer queue. Time
stamp the buffers for playback time as you queue them with the current
host time plus additional time for how far they are from the front of
the buffer. For example, the first 32 samples are stamped with host
time. The second 32 are host time plus delta. The third are host time
plus delta * 2, etc. Delta is the amount of time it would take to play
32 samples (1 second * 32 samples / Sample Rate).
if i do something like this how do i get the right pause between the
call's to myOwnProcess?
When you pull the buffer off of your queue. compare it's timestamp to
now. If the buffer is older than some threshold (and there are more
buffers) discard it and pull the next one until it is a fairly recent
buffer. Draw based on that buffer and wait for Delta time to expire
(same formula as above).
The actual display object is in Cocoa, so if i used a NSThread to split
up the buffer and do the display, how would i sync it to the callback
rate?
The method I outlined will sync the display, but it will drop a LOT of
frames, almost all due to the fact that the underlying graphics system
will not refresh that quickly (your asking it to refresh at over 1300Hz
for 32 samples @ 44100Hz).
Personally, if your visual doesn't work well drawing more than 32
sample at a time, I would look at revising your visual. Even at 512
samples drawn that is an 86Hz refresh rate, which is faster than many
monitors can keep up.
--
Reality is what, when you stop believing in it, doesn't go away.
Failure is not an option. It is a privilege reserved for those who try.
David Duncan
_______________________________________________
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.