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:
- 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.
- 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.
- 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.