Database puts "media" in media players
December 01, 2010
Developers can turn to relational embedded database management technologies for the scalability required by modern portable media players.
Portable media players offer new ways to deliver and access content. Limitations that device manufacturers have been able to take for granted, such as amount of content and delivery method, are gradually eroding. In addition to metadata about media stored on the device, such as artist, album, and song names, players with network connectivity can map recommendations from friends. With increasing storage capacity and the new possibilities that come with ubiquitous connectivity, portable media players are set to handle more data than ever before.
As with any consumer device, cost remains a critical factor in portable media player design. Software developers must create new techniques to manage music, video, and image files that leverage the limited hardware available for these products. The amount of data that must be managed can easily exceed a device’s working memory, posing unique challenges to developers who want to access that information for a variety of purposes.
Software developers can turn to relational embedded database management technologies for the scalability required by modern portable media players. A database file stored on inexpensive NAND flash memory is a simple solution because the details of storage and retrieval are handled by algorithms with proven scalability and reliability, adapted to the unique requirements of portable devices. Design engineers can capitalize on this advantage to reduce cost and time to market.
Organizing media files
There are many ways to find a song on a portable media player. A user might look up the artist and album, then select the song from the album’s track list. Or the user might search for the song by title after browsing through an alphabetical list. Sometimes the song is chosen randomly.
To do this, the media player must have a list of all songs stored on the device. This list can be generated when the player is started or when the song is transferred to the device if a media-aware protocol such as Media Transfer Protocol (MTP) is used. This list should be stored persistently so that it is not recreated each time the device is started, and should allow the data to be browsed in several different ways. If songs are added or removed, it should not be necessary to rebuild the entire list.
Hardware limitations
Portable media players are designed for a single task: playing music and video. These devices typically use dedicated DSP hardware to decode media, leaving the general-purpose CPU free to operate the user interface and send media to the DSP. Unlike a desktop application, where a rogue task can sometimes consume all CPU resources, media player software is carefully designed to limit the amount of time spent on each task so that media playback is never interrupted.
Media files and their metadata are stored on NAND flash memory or miniature hard drives. While these are inexpensive and persistent, both types of storage are divided into blocks that affect performance. Metadata is accessed randomly, so data is often read into RAM far in advance of when it is needed. For this reason, it is necessary to cache frequently accessed blocks so that these extra reads are not wasted.
But because available memory is limited, media player software must use a predetermined amount of RAM for general processing. The total RAM required for a software component, such as a lightweight relational database, is based on four measurements: static code, static data, stack, and heap. The exact amount of RAM required, or footprint, depends on which parts of the software are actively running at any given time.
Embedded relational database
When software developers implement a custom data management framework for a portable media player, the data model is usually hard-coded in the framework itself. Changes to the data model must be made carefully so that worst-case guarantees are not violated. The alternative, developing a generalized data management framework, is difficult to justify for a single product.
While a traditional database management system requires too much overhead to be used on a portable media player, the core database technology and algorithms are still valuable for portable media players. An embedded relational database provides a standard interface for reliable data management that is suitable for media players and other portable devices. The database is invisible to the consumer and requires no administration because it is linked directly into the application as an in-process software library.
Database technology provides applications with a practical model for data storage that is powerful yet easy to use. Information is organized into tables with a predefined structure. By hiding the exact format used to store information, the database can cache information intelligently to optimize performance while providing a wide range of features – transactions, recovery, search, and shared access – that would otherwise be difficult to implement and maintain in a single application.
Application code is frequently reused to expand an existing product line or to jump-start development of a new product. Using a database gives an application a consistent architecture for persistent data storage, making it easy to add new features and migrate the application code to a new environment. Using a database is a good long-term investment because it lets applications scale through the entire life cycle of the application.
Portable media players need consistent, scalable performance across all operations, whether reading or writing to the database. Indexes are used to efficiently search the database and traverse the relationships between tables. B+ tree indexes are optimized to minimize disk I/O and offer consistent performance regardless of table size, even with limited RAM.
When a sudden power failure or crash occurs while writing to a file, data corruption and inconsistency can result. To prevent corruption, embedded databases first write each change to a separate log file before modifying the database file. Using the log, incomplete changes can be rolled back to restore the database to a known good state.
Rollback helps application developers cope with errors. If the software on a media player were to encounter a media file that is partially corrupt, it might have already added data about the file to several tables in the database. Rollback lets the application group changes together into an atomic transaction that either finishes completely or not at all. When an error occurs anywhere in the transaction, the application can roll back all changes with a single API call, regardless of where in the process the error occurred.
Solving media player storage problems
Nearly every consumer now owns a portable media player in some form, and the demand for more storage capacity in these and other embedded devices continues to drive down the cost of storage hardware. But new hardware capabilities present new problems to media player software.
ITTIA DB SQL is a pure relational database library suitable for portable media players where performance matters (see Figure 1). No matter how large the collection of media files grows, media will be sorted, searched, and navigated rapidly because the database library maintains indexes on key fields in the metadata. Interoperability, communication, and synchronization with other consumer electronics are areas of expansion for application developers. Device applications embedded with ITTIA DB SQL can leverage row-level locking to add concurrent access to the metadata for other devices. The database library exercises tight control over memory and code footprint and stores data in a portable format so that media player developers can face current hardware restrictions while providing for the needs of the future.
Sasan Montaseri is the founder and president of ITTIA. He has more than 20 years of experience in the embedded database business arena. He holds a BS in Electrical Engineering from the University of Kansas with a minor in Mathematics. He was a member of PI MU Epsilon National Honor Society of Mathematics.
Ryan Phillips is a lead database engineer at ITTIA. He has more than 15 years of software and database development experience. He holds a BS in Computer Science from the University of Washington.
ITTIA
425-462-0046
www.ittia.com