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 15:32:47 -0700
I forgot to say that, most likely, this is a symptom of a time stamp
issue. You might be able to mask the problem most of the time by
saying that your device is not relatively constant rate. But, the
HAL's check is a very broad check and only flags things that are
really far outside of the norm.
Since this situation isn't happening all the time, I think that this
is likely saying that you have a very large problem with how you
generate your time stamps in this circumstance that bears checking out.
On Aug 9, 2005, at 12:32 PM, Jeff Moore wrote:
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:
40apple.com
This email sent to email@hidden
--
Jeff Moore
Core Audio
Apple
--
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