Media Device Detection and Synchronization

QNX CAR automates media device detection and synchronization. When the user attaches a device for the first time, the mm-detect and mm-sync services coordinate to upload the device's metadata to its QDB database.

The interaction between these components proceeds like this:

Architectural diagram with device detection and synchronization components highlighted and their order of interaction enumerated
Figure 1. Media device detection and synchronization
  1. Detecting device attachments

    Device publishers don't physically detect when users attach or detach devices. Other OS-layer processes—device drivers and protocol stacks—monitor I/O hardware for physical state changes that indicate device attachments or detachments (e.g., SD card insertions or USB device connections). Because they interface with hardware, the drivers and stacks contain up-to-date details on the physical connectivity and mountpoints of devices. The publishers must communicate with these other processes to learn of device attachments and detachments.

  2. Obtaining device information

    Different publishers use different methods for obtaining the latest device information. The usblauncher publisher queries the io-usb process for device information (for details, see "The usblauncher Service" in the Device Publishers Programmer's Guide). The mmcsdpub and cdpub publishers monitor specific /dev paths and when they notice updated entries, they communicate with the drivers to obtain device information (for details, see "Role of device drivers and mcd").

  3. Publishing device, driver, and filesystem information to PPS

    After retrieving information about newly attached devices from other OS processes, the publishers output this information in text format to PPS objects. Each object stores information that describes a single device. Also, the publishers use different object types for storing device connectivity, driver process, and filesystem information, as explained in the "PPS object types" section in the device publisher documentation.

    When publishers learn from a driver or protocol stack process that a device has been detached, they delete the PPS objects related to that device.

  4. Reading device information from PPS

    The mm-detect service keeps track of which devices are attached to your in-car system by monitoring the filesystem information objects in PPS. When a new object is created following a device attachment, mm-detect reads the new device's information from the object, and stores this information.

  5. Initiating synchronization

    To start synchronizing the device's media metadata, mm-detect loads the device's QDB database into memory (see the "Loading QDB databases" section in the QDB Developer's Guide for information on how this is done). Next, mm-detect passes the device's mountpoint and the name of its database to mm-sync. The database name is constructed from the device's unique ID (UID), which was read (along with the mountpoint) from the PPS object. The synchronization path given to mm-sync is the root directory of the device's filesystem, which means all media files on the device have their metadata synchronized.

  6. Extracting and storing media metadata

    The mm-sync service uses media libraries (not shown) to read filepaths and other information from media tracks found on the device. Based on its internal mapping of metadata fields to database fields, mm-sync copies the extracted metadata into the appropriate tables and columns. At this point, applications can query the QDB database to obtain creation and runtime information on all audio and video content found on the device.