An mm-pnp child thread monitors a device-related PPS object and indirectly invokes QDB to load the appropriate database in response to a device attachment. Then, a second thread synchronizes the device's media metadata using mm-sync. Finally, a third thread plays the content using mm-renderer.
These tasks are performed in an automated, ongoing process. Understanding this process is essential if you want to adapt mm-pnp to demonstrate a different synchronization and playback policy, or if you want to use the code as a basis for your own media apps.
Figure 1. Interaction between mm-pnp and multimedia components
Reporting device attachments
The device publisher that monitors the hardware events triggered by the device's attachment (e.g., USB bus notifications or SD card insertions) writes the device's information to PPS.
Extracting device information
The device monitoring thread of mm-pnp reads this information, which includes the mountpoint and device type, from a special PPS mount object (by default, /pps/qnx/mount/.all). The thread then saves the extracted information in the mediastore profiles list.
Publishing the database configuration
Based on the database settings defined for the device type, the same thread publishes the configuration for the QDB database that will store the device's media information.
Loading the database
When mm-pnp publishes the PPS object to the QDB configuration directory (/pps/qnx/qdb/config/), the QDB server begins loading the device's database.
Reporting database status
The QDB server reports the outcome of the database load operation by writing the database's new status to a PPS object in the QDB status directory (/pps/qnx/qdb/status/).
Looking up device information
The database monitoring thread reads database statuses from a special PPS object (by default, /pps/qnx/qdb/status/.all). When it learns that a database has been loaded successfully, the thread uses the database name to look up the corresponding device's information in the mediastore profiles list. From this list, the thread obtains the device's mountpoint and synchronization path, which it then stores in a new entry in the pending synchronizations list.
Starting synchronizations
Before it can start a synchronization, mm-pnp must check the limits on the number of concurrent synchronizations allowed for all device types and for the device type of the first entry in the pending synchronizations list. If these limits have not been exceeded, the database monitoring thread passes the mountpoint and synchronization path in the first list entry to mm-sync, which starts uploading the device's media information to its database. Then, the thread moves the entry from the pending synchronizations list into the active synchronizations list.
If the limits have been exceeded, mm-pnp instead waits for one of the active synchronizations to finish and when this happens, it starts another one.
Note: If you extend the DB manager module to define additional operations for handling database status changes, the database monitoring thread should perform these operations right after it calls mm-sync.Writing file information to the database
The mm-sync service reads file information from media tracks on the device and invokes QDB to store this information in the device's database (which was loaded in Step 4).
Notifying about file information uploading
When mm-sync finishes uploading the file information to the database, the service generates the MMSYNC_EVENT_MS_1PASSCOMPLETE event. The synchronization event-processing thread receives this event and in response, looks up the device's entry in the active synchronizations list to obtain the database name.
Specifying a playlist
The same thread uses the database name to define a playlist for playing the device's media content. The playlist is based on an SQL query that retrieves information from all files listed in the database.
The thread then invokes mm-renderer to:- create a new context
- attach the output to the default sound device to enable audio output
- attach the newly defined playlist as the input
- start playing the playlist
Note: Because you can name only one output device for mm-renderer to use, mm-pnp stops any current playback when it processes an MMSYNC_EVENT_MS_1PASSCOMPLETE event. So, the program always begins playing the media content of the latest device attached to the system.Querying filenames in the database
The mm-renderer service extracts the names of all media files listed in the database by running the SQL query that mm-pnp provided as the playlist basis. The service must know the filenames to play their media content.
Outputting playlist tracks
The mm-renderer service then starts playing the tracks in the playlist. The tracks are played in sequence, with no repeating, until the entire playlist has been played.