Setup and Command Monitoring

At startup, mm-control parses its command-line options and a configuration file (if specified), which lists the default outputs and zones for media playback. The mm-control service then creates and begins monitoring a Persistent Publish/Subscribe (PPS) object, to accept commands from client applications for performing media operations.

These setup tasks are performed in an automated, ongoing procedure. Understanding this procedure is necessary if you want to write a replacement service for mm-control or write your own media applications that use mm-control.

The mm-control process performs the following setup steps:

  1. Command-line and configuration file parsing

    At startup, mm-control parses its command-line options, which may define:
    • the path to the configuration file, which defines the default outputs and zones available for media playback
    • process metrics, including the scheduling priority level and a flag for running in the background
    • the verbosity level, which is useful for debugging
    When mm-control learns the path of the configuration file, the service immediately parses that file, verifying that its contents are in proper JSON format. If so, mm-control builds up lists of default outputs and default zones by copying the data from the entries in the outputs and zones list objects found in the configuration file into internal arrays.

    If the file contents are not properly formatted, mm-control reports an error in sloginfo and skips the step of setting up a default set of outputs and zones.
  2. PPS interface setup

    The mm-control process calls open() to create a PPS control object (/pps/services/mm-control/control) that provides a mechanism for client applications to issue media commands. This PPS object is opened in delta mode, which allows any process reading the object (mm-control or an HMI application monitoring media operations) to receive only the changed object content when the object is updated. The mm-control process then calls read() on the PPS control object; this call blocks until the object is updated by another process.

    For information on opening a PPS object with the delta and wait options set, which is necessary to achieve this behavior, see the "Pathname open options" section in the QNX PPS Developer's Guide.
  3. Media command processing

    When a client application writes a command into the PPS control object, the read() call unblocks and returns the new object content, which should contain a syntactically valid command. If so, the appropriate mm-control subsystem then processes the command and writes its outcome to the PPS control object. The client that issued the command can then read the outcome from this object.

    For details on how mm-control parses, executes, and reports the outcome of a command, see Media command processing.

    After processing a command, mm-control issues another call to read() to resume monitoring the PPS control object for new commands. Thus, this third step is repeated each time a command is issued.

The mm-control service runs continuously, so client applications can issue media commands and read their outcomes through PPS at any time. If the mm-control process terminates unexpectedly, an application can restart the service manually to restore support for media operations.