Re: VariSpeed and Timestamps
Re: VariSpeed and Timestamps
- Subject: Re: VariSpeed and Timestamps
- From: Ethan Funk <email@hidden>
- Date: Wed, 17 Nov 2004 14:47:16 -0700
Yep, printf-ing the results fixed the skipping. All looks well from
the time stamp end of things. I guess I have a mistake else ware in my
code. Thanks for helping me understand how VariSpeed works.
Ethan...
On Nov 17, 2004, at 13:56, Doug Wyatt wrote:
On Nov 17, 2004, at 12:43, Ethan Funk wrote:
To check up on the varispeed, I would log the timestamps it pulls
you for, e.g.:
pull 1:
It pulls you at time 1000 for 500 samples.
pull 2:
is the timestamp 1500? if not, error
time 1500, 499 samples
pull 3:
is the timestamp 1999? if not, error
If the timestamps aren't correct, let us know ... if they are, then
check your code further ...
I checked the time stamps using break points. The results are as
follows:
Pull sTime (output) # sTime (input) #
1 37,220,394 1116 16,721,708 512
2 42,873,218 1112 19,318,474 512
3 49,666,285 1116 22,439,039 512
4 55,237,383 1116 24,998,262 512
pulling at 96Ksps, VariSpeed converting to 44.1Ksps on it's input
side. This rate conversion appears to be working from the requested
sample numbers. The sample times however are all over the place.
The delta between pull 1 and 2 on the input side of the VariSpeed is
>58 seconds at 44.1Ksps. It took less than 20 seconds for me to
write down the numbers and continue execution, so the numbers don't
seem to account for that either.
Any ideas?
Don't stop at breakpoints! You'll miss I/O cycles.
Print the numbers. If you want to avoid digging through massive debug
spew, just print a message when the timestamp is not contiguous (i.e.
currentTimestamp != previousTimestamp + previousPullSize).
Doug
_______________________________________________
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