Re: IO Cycle Telemetry Window
Re: IO Cycle Telemetry Window
- Subject: Re: IO Cycle Telemetry Window
- From: Jeff Moore <email@hidden>
- Date: Wed, 31 Aug 2005 13:10:14 -0700
You have to implement the server protocol for each of your devices.
The basic data structures and constants are covered in the file
CAHALTelemetry.h in the PublicUtilities directory of our SDK.
Needless to say, this is not an officially supported API. It's more
or less something we threw together that seemed useful. The code
that's in the SDK is for the client. It is all definitely subject to
change in the future.
That said, it goes something like this:
For each device, create CFMessagePort with the name made with the
printf format kHALIOCycleTelemetryServerPortNameFormat. There are
messages for getting and setting properties and for getting the
telemetry data and clearing the telemetry buffers. There are only two
properties, kHALTelemetryPropertyIsCapturing which turns capturing on
and off, and kHALTelemetryPropertyEndianness which tells the client
what endian the server is sending binary data in. This allows you to
target processes running under Rosetta with a native version of the
client code.
The message data is a serialized CFDictionary whose keys are defined
in CAHALTelemetry.h. The specific kind of data in the dictionary
depends on the message. Property messages contain more data that
specifies the property ID and the data to get/set as it's value.
The telemetry is essentially a stream of
CAHALIOCycleRawTelemetryEvent structs that describe the various
events that can take place during the IO cycle. CAHALTelemetry.h
describes the struct in some detail. The complicated bit is producing
this stream. To do so, you'll need to put code into your engine that
can drop telemetry events into a place where the server code can
gather it and deliver it to clients on demand without adversely
affecting your engine's performance.
I don't have any code I can give you that illustrates implementing a
server. The SDK does have code that implements a client.
CAHALTelemetry.h is part of it, but it also includes the aptly named
CAHALIOCycleTelemetryClient class. This should at least show you what
it should look like on the client side and provide you a way to
validate your implementation.
I'm also happy to answer specific questions about implementing the
server.
On Aug 31, 2005, at 1:03 AM, Stéphane Letz wrote:
>After building HALLab, you choose the "IO Cycle Telemetry Window"
>item from the "New" menu in the "File menu". This brings up the
>window that provides the UI on the telemetry client. Note that the
>process needs to be run as root to use the latency tracing
facilities.
>I should also point out that the source code for the telemetry client
>engine is in our SDK's PublicUtility directory. It is self contained
>so you can drop it into your own test tools as well.
>I'm happy to help you puzzle through the telemetry data.
Concerning the "IO Cycle Telemetry Window", I tried to measure what
happens when an application is used with our used-land driver
(launching iTunes running with our driver running as the default
system driver) but i don't see any data printed in the IO Cycle
Telemetry Window. It works with Built-in or any aggregate device I
also have.
I see a "CAHALIOCycleTelemetryClient::Update: no port" message
displayed by HALLab. Is there anything special to implement in the
user-land device so that it can be measured?
--
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