Chapter 3. Capabilities
Prev   Next

Chapter 3. Capabilities

This chapter describes the ML capabilities tree, the repository of information on all installed ML devices. The capabilities tree tells you everything from the hardware location of a physical device to the range of legal values for supported parameters.

This chapter contains the following sections:

Capabilities Tree

The capabilities tree forms a hierarchy that describes the installed ML devices in the following order from top to bottom, as shown in Figure 3-1:

  1. Physical system

  2. Physical devices

  3. Logical devices

  4. Supported parameters on the logical devices

Figure 3-1. Capabilities Tree

Capabilities Tree

Utility Functions for Capabilities

To access the capability hierarchy, you may either search the capability tree directly or make use of convenient utility functions to perform the search for you. This chapter discusses the baseline functionality provided in the core ML library, but you may also wish to examine the utility library and example code for pre-written alternatives.

Manual Access to Capabilities

Direct access to the ML capabilities tree is via the following functions:

Function Call 

Description

mlGetCapabilities 

Calls the capabilities for an ML object

mlPvGetCapabilities 

Calls the capabilities for a parameter on a given device

mlFreeCapabilities 

Releases a set of capabilities when you have finished using them

This section discusses the following:

Accessing Capabilities

The following code examples show you how to query for the capabilities of your entire capability tree:

Note: All objects in ML are referred to via 64-bit identifying numbers. For example, the 64-bit ID number for the system on which your application is running is ML_SYSTEM_LOCALHOST.

Get Local System Capabilities

The following example shows how you can get the capabilities of the local system. The following code will give you an MLpv list that includes an array of identifiers for all of the physical devices installed on this system:

MLpv* systemCap;
mlGetCapabilities( ML_SYSTEM_LOCALHOST, &systemCap);

Get Physical Devices

To list the number of physical devices on your system, use the following example :

MLpv* deviceIds = mlPvFind( systemCap, ML_SYSTEM_DEVICE_IDS_INT64_ARRAY);
printf("There are %d physical devices\n", deviceIds->length );
if( deviceIds->length > 0 )
  printf("The first device has id %llx\n", deviceIds->value.pInt64[0]);
mlFreeCapabilities( systemCap );

Get Logical Devices

To examine a physical device for its supported I/O paths and transcoders (that is, its logical devices), use the following example:

MLpv* deviceCap, *pathIds, *xcodeIds;
mlGetCapabilities( someDeviceId, &deviceCap);
pathIds = mlPvFind( deviceCap, ML_DEVICE_PATH_IDS_INT64_ARRAY);
xcodeIds = mlPvFind( deviceCap, ML_DEVICE_XCODE_IDS_INT64_ARRAY);
printf("Device supports %d i/o paths and %d transcoders\n", 
pathIds->length, xcodeIds->length);
if ( pathIds->length > 0 )
  printf("The first i/o path has id %llx\n", pathIds->value.pInt64[0]);
mlFreeCapabilities( deviceCap );

Get Parameters Accepted by a Path

Descending still further down the capability tree, you can obtain the capabilities of any particular logical device by again calling mlGetCapabilities . The following example shows how to find the number of parameters that are accepted by a path:

MLpv* pathCap, *paramIds;
mlGetCapabilities( somePathId, &pathCap);
paramIds = mlPvFind( pathCap, ML_PARAM_IDS_INT64_ARRAY);
printf("Path supports %d parameters\n", paramIds->length);
if (paramIds->length > 0)
  printf("The first parameter has id %llx\n",paramIds->value.pInt64[0]);
mlFreeCapabilities( pathCap );

Query Individual Parameters of Logical Devices

At this point, you have descended from the system to the logical device. Still there is one more level: the parameter. Querying the capabilities of a parameter is subtly different because the interpretation of parameters in ML is device-dependent (for example, the legal values for ML_IMAGE_WIDTH_INT32 may be 1920 on one device and 720 on another). Thus, you must pass both a logical device ID and a parameter ID as shown in the following example:

MLpv* paramCap, *paramName;
mlPvGetCapabilities(someLogicalDeviceId, someParamId, &paramCap);
paramName = mlPvFind( paramCap, ML_NAME_BYTE_ARRAY );
if( paramName != NULL )
    printf("Param has name %s\n", (char *) ( paramName->value.pByte ));
mlFreeCapabilities( paramCap );

Note: Because the name of the parameter is being queried on a particular device, the above code will work for all parameters. This includes new device-dependent parameters.

See the mlPvToString(3dm) man page for a simpler way to find a parameter name.

Query Parameters That Describe Parameters

In addition to obtaining the capabilities of device parameters, you may also obtain the capabilities of the parameters used to describe the capabilities themselves. Because the capabilities parameters are not device-dependent, deviceID may be left empty. The following example shows how to find a text name for the capability parameter ML_PARENT_ID_INT64:

MLpv* paramCap, *paramName;
mlPvGetCapabilities(someLogicalDeviceId, someParamId, &paramcap);
paramName = mlPvFind( paramCap, ML_NAME_BYTE_ARRAY);
if( paramName != NULL )
    printf("Param has name %s\n", (char *) ( paramName->value.pByte ));
mlFreeCapabilities( paramCap );

You can get the same result by using mlPvToString, which itself calls mlPvGetCapabilities.

Identification Numbers

There are the following types of ID numbers in ML:

ID Type 

Definition

constant ID 

Constant IDs have defined names and may be hard-coded. They are system-independent. Examples of constant IDs are ML_SYSTEM_LOCALHOST and ML_IMAGE_WIDTH_INT32.

static ID 

Static IDs are allocated by the ML system as new hardware is added. They are machine-dependent and may change after a reboot or as the system is reconfigured by adding or removing devices. The static ID of a device may change if it is removed from the system and then reconnected.

Note: Static IDs should never be written to a file or passed between machines.

Examples of static IDs are the physical and logical device IDs returned in calls to mlGetCapabilities. If you must share such information between machines, you should use the text names (system-independent) that correspond to the static IDs.

open ID 

Open IDs are allocated when logical devices are opened. They are machine-dependent, and have a limited lifetime -- from when mlOpen is called until mlClose is called.

Note: Open IDs should never be written to a file or passed between machines.

You can call mlGetCapabilities (or mlPvGetCapabilities) for any type of ID, but the list that is returned will always be static.

Summary of Capabilities

The following sections describe the capabilities of each type of ML object:

Note: The capabilities are not necessarily used in the order shown.

In these tables, the string in the Parameter column of the table is a shortened form of the full parameter name. The full parameter name is of the form ML_parameter_type , where parameter and type are the strings listed in the Parameter and Type columns, respectively. For example, the full name of ID is ML_ID_INT64.

System Capabilities

Table 3-1 contains the system capabilities listed when a system ID is queried.

Table 3-1. System Capabilities

Parameter

Type

Description

ID

INT64

Resource ID for this system.

NAME

BYTE_ARRAY

NULL-terminated ASCII string containing the hostname for this system.

SYSTEM_DEVICE_IDS

INT64_ARRAY

Array of physical device IDs (these need not be sorted or sequential). For more details on a particular device ID call mlGetCapabilities. This array could be of length zero.


Physical Device Capabilities

Table 3-2 shows the physical device capabilities. The only defined physical system ID is ML_SYSTEM_LOCALHOST.

Table 3-2. Physical Device Capabilities

Parameter

Type

Description

ID

INT64

Resource ID for this physical device.

NAME

BYTE_ARRAY

NULL-terminated ASCII description of this physical device (for example, HD Video I/O or AVC/1394).

PARENT_ID

INT64

Resource ID for the system to which this physical device is attached.

DEVICE_VERSION

INT_32

Version number for this particular physical device.

DEVICE_INDEX

INT32

Index for this physical device. This is used to distinguish multiple identical physical devices (indexes are generated with a consistent algorithm). Identical machine configurations will have identical indexes. For example, plugging a particular card into the first 64-bit, 66-MHz PCI slot in any system will give the same index number. Uniquely identifying a device in a system-independent way requires using both the name and index.

DEVICE_LOCATION

BYTE_ARRAY

Physical hardware location of this physical device (on most platforms, this is the hardware graph entry). This makes it possible to distinguish between two devices on the same I/O bus and two devices each with its own I/O bus.

DEVICE_JACK_IDS

INT64_ARRAY

Array of jack IDs. For more details on a particular jack ID, call mlGetCapabilities. This array could be of length zero.

DEVICE_PATH_IDS

INT64_ARRAY

Array of path IDs. For more details on a particular path ID, call mlGetCapabilities. This array could be of length zero.

DEVICE_XCODE_IDS

INT64_ARRAY

Array of transcoder device IDs (these need not be sorted or sequential). For more details on a particular transcoder ID, call mlGetCapabilities. This array could be of length zero.


Logical Device Capabilities

This section discusses the following:

Jack Logical Device Capabilities

Table 3-3 shows the capabilities for a jack logical device.

Table 3-3. Jack Logical Device Capabilities

Parameter

Type

Description

ID

INT64

Resource ID for this jack.

NAME

BYTE_ARRAY

NULL-terminated ASCII description of this jack (for example, Purple S-video).

PARENT_ID

INT64

Resource ID for the physical device to which this jack is attached.

JACK_TYPE

INT32

Type of logical jack:

  • ML_JACK_TYPE_ADAT (digital ADAT standard jack)

  • ML_JACK_TYPE_AES (digital AES standard jack)

  • ML_JACK_TYPE_ANALOG_AUDIO (analog audio jack)

  • ML_JACK_TYPE_AUDIO (generic audio jack)

  • ML_JACK_TYPE_AUX (generic auxiliary jack)

  • ML_JACK_TYPE_COMPOSITE (composite video jack)

  • ML_JACK_TYPE_DUALLINK (SDI dual link jack)

  • ML_JACK_TYPE_GENLOCK (genlock jack)

  • ML_JACK_TYPE_GFX (digital graphics jack)

  • ML_JACK_TYPE_GPI (general purpose interface jack)

  • ML_JACK_TYPE_SDI (serial digital interface SDI jack)

  • ML_JACK_TYPE_SERIAL (generic serial control jack)

  • ML_JACK_TYPE_SVIDEO (SVideo jack)

  • ML_JACK_TYPE_VIDEO (generic video jack)




JACK_DIRECTION


INT32


Direction of data flow through
this jack:
  • ML_JACK_DIRECTION_BOTH (jack with data
to and from memory) 
    

    • 

  • ML_JACK_DIRECTION_IN (input jack with
data for memory)
    

    • 

  • ML_JACK_DIRECTION_OUT (output jack
with data from memory)
    

    • 



JACK_COMPONENT



_SIZE


INT32


Maximum number of bits of resolution
per component for the signal through this jack. Stored as an integer,
therefore 8 means 8 bits of resolution.


JACK_PATH_IDS


INT64_ARRAY


Array of path IDs that may use
this jack. (These need not be sorted or sequential.) For more details
on a particular path ID, call mlGetCapabilities. This
array could be of length zero.


PARAM_IDS


INT64_ARRAY


List of resource IDs for parameters
that may be set and/or queried on this jack.


OPEN_OPTION_IDS


INT64_ARRAY


List of resource IDs for open option
parameters that may be used when this jack is opened


JACK_FEATURES


BYTE_ARRAY


Double NULL-terminated
list of ASCII feature strings. Each string represents a specific feature
supported by this jack. Entries are separated by NULL
characters (there are 2 NULL characters after the last
string). 



Path Logical Device Capabilities


Table 3-4 shows the parameters for path logical
device capabilities.


Table 3-4. Path Logical Device Capabilities


Parameter


Type


Description


ID


INT64


Resource ID for this path.


NAME


BYTE_ARRAY


NULL-terminated
ASCII description of this path (for example, Memory to S-Video
Out).


PARENT_ID


INT64


Resource ID for the physical device
on which this path resides.


PARAM_IDS


INT64_ARRAY


List of resource IDs for parameters
that may be set and/or queried on this path.


OPEN_OPTION_IDS


INT64_ARRAY


List of resource IDs for open option
parameters that may be used when this path is opened.


PRESET


MSG_ARRAY


Each entry in the array is a message
(a pointer to the head of an MLpv list, where the last
entry in the list is ML_END). Each message provides
a single valid combination of all setable parameters on this path. In
particular, it should be possible to call mlSetControls
using any of the entries in this array as the control's message. Each
path is obligated to provide at least one preset parameter. 


PATH_TYPE


INT32


Type of this path: 
  • ML_PATH_TYPE_DEV_TO_DEV  (path from
device to another device)
    

    • 

  • ML_PATH_TYPE_DEV_TO_MEM  (path from
device to memory)
    

    • 

  • ML_PATH_TYPE_MEM_TO_DEV  (path from
memory to a device)
    

    • 



PATH_COMPONENT



_ALIGNMENT 


INT32


The location in memory of the first
byte of a component (either an audio sample or a video line), must meet
this alignment. Stored as an integer in units of bytes.  


PATH_BUFFER



_ALIGNMENT


INT32


The location in memory of the first
byte of an audio or video buffer must meet this alignment. Stored as an
integer in units of bytes.


PATH_SRC_JACK_ID


INT64


Resource ID for the jack that is
the source of data for this path (unused if path is of type 
ML_PATH_TYPE_MEM_TO_DEV). For details on the jack ID, call 
mlGetCapabilities.


PATH_DST_JACK_ID


INT64


Resource ID for the jack that is
the destination for data from this path (unused if path is of type 
ML_PATH_TYPE_DEV_TO_MEM). For details on the jack ID, call 
mlGetCapabilities. 


PATH_FEATURES


BYTE_ARRAY


Double NULL-terminated
list of ASCII features strings. Each string represents a specific feature
supported by this path. Entries are separated by NULL
characters (there are 2 NULL characters after the last
string).



Transcoder Logical Device Capabilities


Table 3-5 shows parameters for the transcoder
logical device capabilities.


Table 3-5. Transcoder Logical Device Capabilities


Parameter


Type


Description


ID


INT64


Resource ID for this transcoder.



NAME


BYTE_ARRAY


NULL-terminated
ASCII description of this transcoder (for example, Software DV
and DV25).


PARENT_ID


INT64


Resource ID for the physical device
on which the transcoder resides.


PARAM_IDS


INT64_ARRAY


List of resource IDs for parameters
that may be set and/or queried on this transcoder (may be of length 0). 



OPEN_OPTION_IDS


INT64_ARRAY


List of resource IDs for open option
parameters that may be used when this transcoder is opened


PRESET


MSG_ARRAY


Each entry in the array is a message
(a pointer to the head of an MLpv list, where the last
entry in the list is ML_END). Each message provides
a single valid combination of all setable parameters on a transcoder.
In particular, it should be possible to call mlSetControls
using any of the entries in this array as the controls message. Each transcoder
is required to provide at least one preset for each transcoder. 


XCODE_ENGINE_TYPE


INT32


Type of the engine in this transcoder.
The only defined transcoder type is: ML_XCODE_ENGINE_TYPE_NULL



XCODE



_IMPLEMENTATION


_TYPE


INT32


How this transcoder is implemented: 
  • ML_XCODE_IMPLEMENTATION_TYPE_HW  (hardware
implementation)
    

    • 

  • ML_XCODE_IMPLEMENTATION_TYPE_SW  (software
implementation)
    

    • 



XCODE



_COMPONENT


_ALIGNMENT


INT32


The location in memory of the first
byte of a component (either an audio sample or a video pixel) must meet
this alignment. Stored as an integer in units of bytes. 


XCODE



_BUFFER


_ALIGNMENT


INT32


The location in memory of the first
byte of an audio or video buffer must meet this alignment. Stored as an
integer in units of bytes.


XCODE_FEATURES


BYTE_ARRAY


Double NULL-terminated
list of ASCII features strings. Each string represents a specific feature
supported by this transcoder. Entries are separated by NULL
characters (there are 2 NULL characters after the last
string).


XCODE_SRC_PIPE_IDS


INT64_ARRAY


List of pipe IDs from which the
transcode engine may obtain buffers to be processes.


XCODE_DEST_PIPE_IDS


INT64_ARRAY


List of pipe IDs from which the
transcode engine may obtain buffers to be filled with the result of its
processing. 



Pipe Logical Device Capabilities


Table 3-6 shows the parameters for the pipe
logical device capabilities.


Table 3-6. Pipe Logical Device Capabilities


Parameter


Type


Description


ID


INT64


Resource ID for this path.


NAME


BYTE_ARRAY


NULL-terminated
ASCII description of this pipe (DV Codec Input Pipe).



PARENT_ID


INT64


Resource ID for the transcoder
on which this pipe resides.


PARAM_IDS


INT64_ARRAY


List of resource IDs for parameters
that may be set and/or queried on this transcoder (may be of length 0).



PIPE_TYPE


INT32


Type of this pipe: 
  • ML_PIPE_TYPE_ENGINE_TO_MEM  (transcoder
output pipe with data flow from engine to memory)
    

    • 

  • ML_PIPE_TYPE_MEM_TO_ENGINE  (transcoder
input pipe with data flow from memory to engine)
    

    • 




Device Open Options


This section discusses the
following:


Jack Open Parameters


Table 3-7 describes the parameters that are
supported when opening a jack. 


Table 3-7. Jack mlOpen Options


Parameter


Type


Description


OPEN_MODE


INT32


Application's intended use for
the device. Defined values are: 
  • ML_MODE_RO (read only access)
    

    • 

  • ML_MODE_RWE (exclusive access.)
    

    • 

  • ML_MODE_RWS (shared read/write access)

    

    • 



 


The default is defined
by the device's capabilities.


OPEN



_RECEIVE


_QUEUE_COUNT


INT32


Application's preferred size (number
of messages) for the receive queue. The size influences the amount of
memory allocated for this queue when the device is opened. Default is
device-dependent. A NULL value indicates that the application does not
expect to receive any events from the jack.


OPEN



_EVENT


_PAYLOAD_COUNT


INT32


Application's preferred size (number
of messages) for the queue event payload area. This payload area holds
the contents of event messages on the receive queue. Default is device
dependent. A NULL value indicates that the application
does not expect to receive any events from the jack.


The ML_OPEN_OPTION_IDS_INT64_ARRAY returned by
a mlGetCapabilities call using the jack ID returns
a list of these parameters. mlPvGetCapabilities can
then be used to discover allowable values.


Path Open Parameters


The following open parameters are supported when opening a path:


Table 3-8. Path mlOpen Options


Parameter


Type


Description


OPEN_MODE 


INT32


Application's intended use for
the device. Defined values are:
  • ML_MODE_RO (read only access)
    

    • 

  • ML_MODE_RWE (exclusive access)
    

    • 

  • ML_MODE_RWS (shared read/write access)

    

    • 



 The default is defined by the
device's capabilities. 


OPEN



_SEND


_QUEUE_COUNT


INT32


Application's preferred size (number
of messages) for the send queue. This influences the amount of memory
allocated for this queue when the device is opened. Default is device-dependent.



OPEN



_RECEIVE


_QUEUE_COUNT


INT32


Application's preferred size (number
of messages) for the receive queue. This influences the amount of memory
allocated for this queue when the device is opened. Default is device-dependent.



OPEN



_MESSAGE


_PAYLOAD_SIZE


INT32


Application's preferred size (in
bytes) for the queue message payload area. The payload area holds messages
on both the send and receive queues. Default is device-dependent.


OPEN



_EVENT


_PAYLOAD_COUNT


INT32


Application's preferred size (number
of messages) for the queue event payload area. This payload area holds
the contents of event messages on the receive queue. Default is device-dependent.



OPEN



_SEND


_SIGNAL_COUNT


INT32


Application's preferred number
of empty message slots in the send queue. When the device dequeues a message
and causes the number of empty slots to exceed this level, then the device
will signal the send queue event. Default is device-dependent.



Transcoder Open Parameters


Table 3-9 describes the parameters that are
supported when opening a transcoder.


Table 3-9. Transcoder mlOpen Options



Parameter


Type


Description


OPEN_MODE


INT32


Application's intended use for
the device. Defined values are:
  • ML_MODE_RO (read only access)
    

    • 

  • ML_MODE_RWE (exclusive access)
    

    • 

  • ML_MODE_RWS (shared read/write access)

    

    • 



 


The default is defined
by the device's capabilities. 


OPEN



_SEND


_QUEUE_COUNT


INT32


Application's preferred size (number
of messages) for the send queue. The size influences the amount of memory
allocated for this queue when the device is opened. Default is device-dependent.



OPEN



_RECEIVE


_QUEUE_COUNT


INT32


Application's preferred size (number
of messages) for the receive queue. The size influences the amount of
memory allocated for this queue when the device is opened. Default is
device-dependent.


OPEN



_MESSAGE


_PAYLOAD_SIZE


INT32


Application's preferred size (in
bytes) for the queue message payload area. The payload area holds messages
on both the send and receive queues. Default is device-dependent.


OPEN



_EVENT


_PAYLOAD_COUNT


INT32


Application's preferred size (number
of messages) for the queue event payload area. This payload area holds
the contents of event messages on the receive queue. Default is device-dependent.



OPEN



_SEND


_SIGNAL_COUNT


INT32


Application's preferred l number
of empty message slots in the send queue. When the device dequeues a message
and causes the number of empty slots to exceed this level, then the device
will signal the send queue event. Default is device-dependent. 


OPEN_XCODE_MODE


INT32


Application's preferred mode for
controlling a software transcoder. This parameter does not apply to paths.
Defined values are: 
  • ML_XCODE_MODE_AYNCHRONOUS (processing
by a software transcoder is to be initiated by ML). (Default.)
    

    • 

  • ML_XCODE_MODE_SYNCHRONOUS (processing
by a software transcoder is to be initiated by the application).
    

    • 



OPEN_XCODE_STREAM


INT32


Selects between single- and multi-stream
transcoders. In single-stream mode, source and destination buffers are
processed at the same rate. In multi-stream mode, the source and destination
pipes each have their own queue of buffers and may run at different rates
(this is more complicated to program, but may be more efficient for some
intra-frame codecs). Defined values are: 
  • ML_XCODE_STREAM_MULTI (Default)
    

    • 

  • ML_XCODE_STREAM_SINGLE
    

    • 




Accessing and Freeing Capabilities


This
section discusses the following:


Finding a Parameter in a Capabilities List


A parameter
within a message or capabilities list may be found using the following: 
MLpv* mlPvFind(MLpv* msg, MLint64 param);



where:
  • msg points to the first parameter in
an ML_END terminated array of parameters 
    

    • 

  • param is the 64-bit unique identifier
of the parameter to be found. 
    

    • 



mlPvFind returns the address of the parameter
if successful; otherwise it returns NULL. 


Obtaining Parameter Capabilities


All objects in ML are referred to via 64-bit identifying numbers.
For example, the 64-bit ID number for the system running the application
is ML_SYSTEM_LOCALHOST. Details on the interpretation
of a particular device-dependent parameter are obtained using: 
MLstatus mlPvGetCapabilities(MLint64 objectId, MLint64 parameterId, MLpv** capabilities);



where:
  • objectId is the 64-bit unique identifier
for the object whose parameter is being queried. An example is the 
openId returned from a call to mlOpen. The
status ML_STATUS_INVALID_ID is returned if the specified
object ID was invalid. 
    

    • 

  • parameterId is the 64-bit unique identifier
for the parameter whose capabilities are being queried. The status 
ML_STATUS_INVALID_ARGUMENT is returned if the capabilities pointer
is invalid. 
    

    • 

  • capabilities is a pointer to the head
of the resulting capabilities list. This list should be treated as read-only
by the application. If the call was successful, then the status 
ml_STATUS_NO_ERROR is returned.
    

    • 

  • objectid may be either a static ID
(obtained from a previous call to mlGetCapabilities)
or an open ID (obtained by calling mlOpen). Querying
the capabilities of an opened object is identical to querying the capabilities
of the corresponding static object.
    

    It is also possible to get the capabilities of the capabilities
parameters themselves. Those parameters are not tied to any particular
object and so the objectId should be 0.
    

    • 

  • capabilities contains the following
parameters, though not necessarily in this order. Table 3-10
is a shortened form of the full parameter name. 
    

    • 



Table 3-10. Parameters Returned by mlPvGetCapabilities



Parameter


Type


Description


ID


INT64


Resource ID for this parameter.



NAME


BYTE_ARRAY


NULL-terminated
ASCII name of this parameter. This is identical to the enumerated value.
For example, if the value is ML_XXX, then the name
is "ML_XXX".


PARENT_ID


INT64


Resource ID for the logical device
(video path or transcoder pipe) on which this parameter is used. 


PARAM_TYPE


INT32


Type of this parameter: 
  • ML_TYPE_BYTE
    

    • 

  • ML_TYPE_BYTE_ARRAY
    

    • 

  • ML_TYPE_BYTE_POINTER
    

    • 

  • ML_TYPE_INT32
    

    • 

  • ML_TYPE_INT32_ARRAY
    

    • 

  • ML_TYPE_INT32_POINTER
    

    • 

  • ML_TYPE_INT64
    

    • 

  • ML_TYPE_INT64_ARRAY
    

    • 

  • ML_TYPE_INT64_POINTER
    

    • 

  • ML_TYPE_REAL32
    

    • 

  • ML_TYPE_REAL32_ARRAY
    

    • 

  • ML_TYPE_REAL32_POINTER
    

    • 

  • ML_TYPE_REAL64
    

    • 

  • ML_TYPE_REAL64_ARRAY
    

    • 

  • ML_TYPE_REAL64_POINTER
    

    • 



PARAM_ACCESS


INT32


Access controls for this parameter.
Bitwise "or" of the following flags: 
  • ML_ACCESS_DURING_TRANSFER
    

    • 

  • ML_ACCESS_IMMEDIATE (use in set/get)

    

    • 

  • ML_ACCESS_OPEN_OPTION
    

    • 

  • ML_ACCESS_PASS_THROUGH (ignored by
device)
    

    • 

  • ML_ACCESS_QUEUED  (use in send/query)

    

    • 

  • ML_ACCESS_READ
    

    • 

  • ML_ACCESS_SEND_BUFFER  (only in 
mlSendBuffers)
    

    • 

  • ML_ACCESS_WRITE
    

    • 



PARAM_DEFAULT


Same type as param


Default value for this parameter
of type ML_PARAM_TYPE. This parameter may be of length
0 if there is no default.


PARAM_MINS


Array of same type as 
param 


Array of minimum values for this
parameter (may be missing if there are no specified minimum values). Each
set of minimum and maximum values defines one allowable range of values.
If the minimum equals the maximum,  the allowable range is a single value.
If the length component is 1, there is only one legal
range of values. The length component will be 0 if
there are no specified minimum values. 


PARAM_MAXS


Array of same type as 
param


Array of maximum values for this
parameter. There must be one entry in this array for each entry in the 
PARAM_MINS array.


PARAM_INCREMENT


Same type as param


Legal param
values go from a minimum to a maximum in increments. The length will be 
0 if there are no specified minimum values. Otherwise, length
will be non-zero.


PARAM_ENUM_VALUES


Same type as param


Array of enumerated values for
this parameter. The length component will be 0 if there
are no enumeration values.


PARAM_ENUM_NAMES


BYTE_ARRAY


Array of enumeration names for
this parameter (must have the same length as the PARAM_ENUM_VALUES
 array). The length of the parameter is the total length of
all of the strings, including the NULL separators,
and the double-NULL terminator.



Freeing Capabilities Lists


To
return a capabilities list (obtained from either mlGetCapabilities
 or mlPvGetCapabilities) to the system, use
the following:
MLstatus mlFreeCapabilities (MLpv *capabilities);



where capabilities is the capabilities list 



Return status:
ML_STATUS_INVALID_ARGUMENT
Capabilities pointer is invalid



ML_STATUS_NO_ERROR
The call was successful





Prev Table of Contents Next
Chapter 2. Parameters  Chapter 4. Audio/Visual Paths