30°C Power On 12 to 36 watts - for fanless sealed system design ...

ESE Magazine Jan/Feb 06
16
MP3 players: the music database
gets database software
By Steven T. Graves, McObject
Seen in one light, MP3 players are a walking database with sound attached.
WHILE MANY consumer electronics
devices must store and retrieve data, it
is the digital media player (or MP3
player) that most resembles a walking
database. Music fans buy the devices so they can
carry around hundreds of hours of audio, instantly
accessing songs according to the “metadata” of
artist, album, title, genre, and playlist. Without the
ability to extensively index, cross-reference and
search a music collection according to the user’s
wishes, the devices would have little appeal.
Less obvious is data management’s role in
extending MP3 players’ battery life and lowering
their manufacturing cost—but Japan’s JVC
Company sees the connection. In late 2005, the
company released what is probably a first: its
new Alneo XA HD500 studio quality digital
media player incorporates a commercial embedded
database management system (DBMS). The
new design reflects digital audio players’ memory
and CPU constraints, which are extreme
even for consumer electronics. JVC found that
the right off-the-shelf database helps use these
resources more efficiently.
Reducing RAM
In an MP3 player, RAM is precious for two reasons:
using less memory reduces the device’s
bill-of-materials cost, lending an important manufacturing
cost advantage, and most RAM within
the device is reserved for the playback buffer
that caches the MP3 stream. Low-end CPUs are
also deployed to minimize cost, and CPU cycles
must be dramatically minimized, to afford a long
playback per recharge.
Playlist Album
PlayListSong
Song
?Genre
Figure 1: Data model of an MP3 player.
Artist
Early in the design process, the JVC engineers
determined it would be difficult to obtain the
desired efficiency, and meet a stringent development
schedule, writing their own data management
code. They began exploring the alternative:
integrating a proven commercial DBMS within
the MP3 player’s embedded software.
The question remained, though, what kind of
database would work. “Enterprise” DBMSs,
designed to serve as corporations’ centralized
data stores were an impossible fit due to cost
and footprint; “embedded” database sounds
closer, except that only a small subset of embedded
databases are intended for real-time
embedded systems (most are meant to be
embedded in packaged software applications).
In-memory
For resource-constrained embedded devices, a key
distinction within the embedded database category
is on-disk DBMS, versus in-memory DBMS.
Most embedded database systems manage data
on-disk, and are designed to cache frequently
requested data in memory – for faster access –
but to write database updates, insertions, and
deletes through the cache to be stored to disk. A
newer approach is the in-memory database system
(IMDS), which eliminates disk access and
stores data in main memory, flushing to disk only
when commanded to do so by the application.
In-memory data management emerged as
the better fit for JVC’s MP3 player. A key issue
was on-disk databases’ indexes, which enable
quick access to related records. To avoid disk
access—which could potentially lead to playback
interference in the MP3 player—the developers
determined they would need to cache all
of the on-disk database (data and indexes).
Freeing memory
A great deal of redundant data is stored in on-disk
databases’ indexes that manifest the relationships
between data entities. With such a database this
is desirable because if the required data exists in
the index, the system can avoid the disk I/O that
would otherwise be needed to access the data
file. Disk I/O is expensive (in performance terms),
so on-disk databases can justify the extra storage
space to hold redundant copies of data in indexes.
But in-memory databases never go to disk. There
Figure 2: Indexes to implement relationships.
is no disk I/O to avoid, so the redundant index data
can be eliminated, thus freeing memory.
In making their database selection, the JVC
engineers also noted that the software logic to
accomplish caching and disk I/O—which are
integral to on-disk databases but non-existent in
in-memory architectures—posed significant
CPU demands. By eliminating these demands,
the in-memory database delivered better performance
with a less powerful CPU, and allowed
the CPU to be “clocked down” during certain
operations to maximize battery life.
Start-up time
Engineers were also concerned about the startup
time for provisioning the in-memory database.
On-disk databases can be used immediately
after the application opens the database,
whereas an in-memory database is initially
empty and must be populated (“provisioned”)
with data. But in the final analysis, the modest
size of the in-memory MP3 database eliminated
this potential issue. For a database providing
access to 5000 songs, the in-memory database
required just 1 MB if the average song title
string length was 20 characters; if all the song
titles were the maximum 512 characters, the
database was about 2 MB. With micro drive
transfer rates up to 33 MB per second, the inmemory
database could be provisioned in a time
span well within usability thresholds. The competing
on-disk database software created a
database that was 7 MB in size.
www.mcobject.com