Consumers have massive amounts of content at their disposal, and they want their cars and personal lifestyle devices to handle that content effortlessly, whether it's music stored on Flash disks, movies burned onto DVDs, or video streaming through the airwaves. Consider, for example, the following scenario: While visiting a friend, Eric copies some songs to his new UFD (USB Flash disk). A couple of hours later, he drives home and inserts the UFD for the first time into a home media device. The device scans the UFD for the first audio file or play list, retrieves metadata about the file, displays the song information, and begins playing. While playing, it automatically synchronises all the other songs, videos, and photos stored on the UFD to a local database, using metadata embedded in the various files. Before the content is completely synchronised, Eric presses a menu button to request all 1980s dance songs. The device automatically generates a playlist and schedules it to play. The device is still performing synchronisation and generating the playlist when Eric removes the UFD and plugs it into his laptop computer. Using the laptop, he adds some new songs to the UFD. Eric reinserts the UFD into the entertainment device. The device recognises that the UFD was previously inserted and continues the synchronisation where it left off, including the newly added content. It also continues to play songs from the 1980s dance playlist that it was generating before Eric removed the UFD. Eric now leaves the device playing - with UFD still inserted - and goes to a second device in another room. From this second device, he selects songs from the remote UFD (using the database on the first device) and listens to it
on headphones connected to the second device. Eric can also control the first device from the second one, for example setting the volume or creating a new playlist.
Future-proof devices

This scenario looks at just one data source, a UFD. But imagine Eric's device could, without design changes, also perform these functions with various DVDs, CDs, iPods, UPnP devices, PlaysForSure media players, Bluetooth cellphones, and various other media. This, in a nutshell, represents the challenge facing designers of next-generation multimedia products. To begin with, a device must connect to any data source, organise the data, and initiate proper data-processing paths. It must also support industry standards for media storage and media connectivity, as well as standard decode and encode formats: MP3 Standard, WMA9/10, MPEG-4, etc. Moreover, it must have the flexibility to support new media, new streaming content,and new DRM (digital-rights management) techniques without compromising its original behavior. And it must make any software updates quick and failure-proof. To achieve this upgradeability, the software will use a modular design where each function (HMI, multimedia controller, etc.) exists as a component that can be developed, tested, and replaced independently of other components (Figure 1). In this approach, each component is a system service that presents itself to other components via an API. To maximise performance, the components will set up bounded, private memory areas for high-speed, zero-copy movement of data. The device must also address other market requirements. For example, it must provide a simple, responsive user experience: the software must support instant-on performance, extremely simple operation, and fast, predictable response times. For instance, the software must always respond quickly to user commands, even if the device is busy ripping a CD or recording a satellite radio broadcast. The device also needs to be reliable: it must never freeze or require a reboot. Consequently, the software architecture has to monitor itself and dynamically heal itself should any problems arise. It must also keep downloaded games and other untrusted software cleanly isolated from critical programs.
Essential services
In its simplest form, a multimedia-enabled system must support the components illustrated in Figure 1. Figure 2 provides an expanded view and shows how the components have been implemented in the QNX Multimedia Solution. Let's look at how these components can address the design considerations described above.
Identify & Connect
This component handles the identification and connection of Flash disks, CDs/DVDs, iPods, mobile handsets, and other media-storage devices, as well as webcasts, satellite broadcasts, and other streaming content. It also "hides" device dependencies and DRM requirements from other software components, allowing for easy upgrades and for new media sources and DRM schemes. To offer a successful user experience, the Identify & Connect component must present other software components with a unified view of all connected storage devices. For instance, it must present UFDs and Bluetooth phones in the same, consistent fashion. That way, the user can select content and build playlists, regardless of where that content is stored. The system may need to isolate device types from one another and make them independently upgradeable. For instance, in Figure 3, the various file systems (io-fs) used by Identify & Connect can be individually started, stopped, or upgraded. They can also run simultaneously to support multiple connected devices. Most multimedia products must tolerate sudden loss of power without corrupting data. To satisfy this requirement, Identify & Connect can use a fault-tolerant file system such as the QNX transaction file system, which not only provides self-healing but also offers encryption to keep internal disks and Flash memory secure from tampering.
Play & Record
This component includes decoders and encoders for processing the media and rendering it to an output. It also provides a level of abstraction to the other components. This component can hide hardware-assisted decoders and audio-video hardware dependencies. Often, a hardware vendor that offers a multimedia DSP will provide a services-library API to the main CPU for control and data transfer. The Play & Record component can hide this API (application-specific interface) from the other software components, allowing for greater hardware independence while still ensuring high performance.
Organize
Thousands of files may reside on a storage device. This data, along with the device information (for instance, the serial number of a UFD) must be organised in a way to make file navigation quick and easy for the user. The Organize
component handles this task.
Multimedia controller
The multimedia controller drives the other components and typically provides high-level services to the HMI. It also manages the device policy.
For instance, if the user inserts a UFD, this policy determines whether the device should catalogue the disk begin playing a song, or execute another task. A flexible and reliable multimedia controller is key to handling these scenarios successfully. The controller may expose several APIs to other components. These include APIs that, for example, provide notification of device insertion and removal, control the play mode (next/previous, pause, seek, random, repeat, scan, etc.), synchronise and browse storage devices, or manage playlists.
Human-machine interface
This component uses the multimedia-controller APIs and supports multimodal input and display. The HMI could be a touchscreen or voice-control system,
or both. The HMI could even be managed remotely, via a simple agent
program that communicates with a remote Web browser or with a Java or Flash interface.

Figure 1: Essential services for a multimedia-enabled embedded system.

Figure 2: A full implementation of the components outlined in Figure 1.

Figure 3: Using multiple concurrent file systems to support a variety of devices.