Re: IO Cycle Telemetry, USB Audio and AC-3 questions
Re: IO Cycle Telemetry, USB Audio and AC-3 questions
- Subject: Re: IO Cycle Telemetry, USB Audio and AC-3 questions
- From: Jeff Moore <email@hidden>
- Date: Tue, 9 Aug 2005 12:32:42 -0700
The telemetry is saying that the HAL is complaining about your time
stamps and is overloading (thus dropping data on the floor). In this
specific case, it is saying that your time stamp is early. Early
means that the time stamp says it is for a time that is very large
amount of time before the time the HAL's clock predicted for the next
time stamp.
The HAL only looks for early time stamps for devices that declare
that they are relatively constant rate via the
kIOAudioEngineClockIsStableKey key in the IO registry. In the absence
of that key, the HAL assumes that the device is relatively constant
rate if it has the USB transport type. Note that you set this key's
value with the method IOAudioEngine::setClockIsStable().
On Aug 8, 2005, at 8:10 AM, Fabian Renn wrote:
Hi again,
I may sound repetitive, but again: i'm working on a driver for a
usb audio device. My driver works fine when i work with buffer
sizes around 6144 samples. Yet AC-3 needs a buffer size of 1536
samples, and thats where the problems begin. When working with 1536
samples i keep on getting clicks in my sound. Now I'm checking with
the IO Cycle Telemetry but i'm not quite sure what the values mean.
With a buffer of 1536 samples i get values in the Zero:samp column
about every 4th row. The whole row is black. Every now and then i
get red rows: Looking at the detailed view of the red row i get a
red row that starts with '0 Early'. What does this mean ( copy
below )?
The problem with usb audio, is that the HAL can only get an update
about the buffer locations every 1 ms and the time stamp resolution
is at most 1 ms ( because a usb frame takes 1 ms to process ). I'm
already trying to smooth this out as much as possible: first of
all, i try to smooth out my outgoing frames as much as possible, so
that there are not too many variations of how many bytes are
transfered with each isoc frame; i take a time stamp of the
frTimeStamp value for every frame that will cause a wrap.
Furthermore I add/remove a couple of nanos to this value according
to how many bytes the frReqCount value is away from 48 samples ( at
48 kHz sample rate ) ( because the time stamp of frTimeStamp was
taken after the whole frame completed. Yet if only, for example 24
samples, were transfered, the wrap would have happened a half a ms
earlier ). My driver logs the time stamps and i'm getting a
variation of about 1 ms ( the difference between two time stamps is
always around 32-33 ms, ideally i should be getting exactly 32 ms
( 1536 / 48 ) ). Is this variation too much?
My guess is that the clicking is coming from the
getCurrentSampleFrame method. At first i would always return a
calculated buffer location, that i calculated from validating the
frame lists when each frame completes. I do this validation every
time i get a usb completion, and every time clipOutputSamples is
called ( exactly like in AppleUSBAudio ), but no more than that.
This resulted in immense clicking at a buffer size of 1536. Now,
when getCurrentSampleFrame gets called, i get the current usb frame
from the usb controller and take the difference from the usb frame
when my sample buffer pointer ( the one that gets calculated in my
frame list validation routine ) was last updated. With this
difference i calculate a minor offset to the sample buffer pointer.
This reduced the clicking a lot, but didn't eliminate it totally.
Does anyone have some tips?
Greetings
Fabian
Black Rows:
Start Offset Late Rate Now:samp
Now:host In:samp In:host Out:samp Out:host Wake:samp
Wake:host Zero:samp Zero:host
31.949 10.657 0.035 1.000072 778807 31.949
778147 18.185 779465 45.645 778825
32.312 778752 30.781
42.612 10.663 0.029 1.000072 779319 42.612
778659 28.852 779977 56.313 779337 42.987
53.283 10.671 0.033 1.000072 779831 53.283
779171 39.520 780489 66.980 779848 53.634
63.952 10.669 0.035 0.999940 780343 63.952
779683 50.176 781001 77.633 780364
64.368 780288 62.786
74.625 10.673 0.055 0.999940 780856 74.625
780195 60.842 781513 88.299 780885 75.236
85.273 10.647 0.036 0.999940 781367 85.273
780707 71.508 782025 98.965 781384 85.624
95.946 10.673 0.043 1.000045 781880 95.946
781219 82.183 782537 109.642 781900
96.376 781824 94.784
106.615 10.669 0.035 1.000045 782391 106.615
781731 92.850 783049 120.310 782411 107.028
117.283 10.668 0.035 1.000045 782903 117.283
782243 103.517 783561 130.977 782922 117.678
127.949 10.666 0.034 0.999980 783415 127.949
782755 114.179 784073 141.637 783433
128.305 783360 126.784
Red Row:
191.940 10.661 0.031 1.000000 786487 191.940
785877 178.226 787195 205.684 786552 192.289
786432 189.788
0 Early: 1467 ....
_______________________________________________
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
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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