Typical devices and applications used by multimedia are well suited to high-quality playback. But the underlying resource management provided by standard Linux and other general-purpose operating systems renders it impossible to achieve high quality, unless nothing else is running. Designers, though, can achieve major quality-of-service (QoS) improvements in Linux-hosted multimedia player operation by implementing CPU reservations provided by the operating system.
There's no question that multimedia technologies have become commodities, and that players are now ubiquitous. MPEG-2 video players are available in satellite receivers, delayed television players, portable DVD players, cell phones, and the workstations that spawned the Internet age. Likewise, MP3 audio players are in car radios, PDA devices, cell phones, and workstations.
However, this ubiquity has forcefully exposed the shortcomings of the traditional Ethernet infrastructure and the timeshare scheduling. Low-resolution, small-frame video; clipped and tinny audio; stalled video; lost audio; and poorly synchronized audio and video are the common experience of every Internet user, no matter the processor speed, the amount of memory available, or even the Internet connection speed. To assure adequate performance on both network-sourcing and stored-content players, players are limited to single functions because of the inability to assure QoS in the presence of multiple processing tasks.
Now, a dramatically effective new scheduling policy changes all of that. It enables multimedia players, operating concurrently with arbitrary processor loads, to secure the computational resources they require to operate continuously with a guaranteed high QoS.
Multimedia player implementation: Figure 1 illustrates the devices and processing stages typically present in multimedia generation and presentation devices. The upper pipeline illustrates the content generation process, starting from sampling of the physical environment and leading to persistent storage or network transmission of the recorded event. Likewise, the lower pipeline illustrates the content presentation process, starting with content retrieval from storage or a network, and leading to video and audio recreation. While this article focuses on the presentation pipeline and the example below uses disk-based rather than Internet-sourced streams, the described reservation mechanisms apply to all stages.
The multimedia player discussed below was executed on a 662-MHz Pentium III Dell OptiPlex GX200 with an Intel i810 Analog Devices AD1881 sound device; an nVidia Vanta video graphics controller; ALSA 0.5.10 drivers for sound (with the emulated OSS core); Xfree86 3.3.6 for video; and RealPlayer 8.0.1 for video presentation. TimeSys Linux/RT 1.2, Linux 2.4.2-pre3 was the operating system used. The test multimedia clip, New Line Cinema's 2001 Lord of the Rings film trailer, is an 11.4-Mbyte, 1:46-min, 1000.1-kbit/s RealMedia file with 64-kbit/s stereo audio.
Resource reservations: A reservation consists of a guaranteed-available-utilization duty cycle for a single resource, such as CPU runtime, memory pages, memory bandwidth, network buffers, network bandwidth, disk blocks, or disk buffers. For simplicity, only CPU reservations are discussed in detail here. But other reservations are possible, and some are already available on actual Linux platforms.
A reservation has parameters that define its periodicity, the deadline within each period, and the amount of time reserved for use within those parameters. The parameters include "T" for the period, "C" for the uninterrupted computation time, and "D" for the relative deadline in each period.
Additionally, each reservation has a depletion policy parameter that describes whether tasks attached to the reservation are allowed to use the reserved resource when the reservation becomes depleted within each reserved period. "Hard" reservations deny use of reserved resources after completion of C in each period. "Soft" reservations grant usage of reserved resources to attached tasks after completion of C in a period, but in competition with all other tasks in the system.
Figure 2 illustrates the depletion and replenishment behavior of reservations. Another way to view a hard reservation is that in addition to protecting the reserved task or tasks, it protects all other tasks from attempted monopolization by the reserved task.
For instance, an application might reserve 2 ms of processor runtime every 10 ms, with a deadline of 8 ms (effectively allocating itself 20% of the processor). The reservation for this would be characterized as:
{resource=CPU, T=10 ms, C=2 ms, D=8 ms, depletion=HARD}
Determining parameters: Several techniques exist to determine appropriate parameters for the resource reservations required by an application. When designing a new application that interacts with physical systems, the system's constraints can often suggest the parameters for appropriate reservations. For example, an application to display video at 33 frames/s might have an appropriate reservation period of 33.33-ms.
Once an initial parameter set is defined, the C value can be "guessed," and the reservation can be tested by a successive-approximation process—better known as trial and error. The reservation can be adjusted via a simple utility, or by the application using the provided API. Determining the optimal value for C can be tricky. But in Linux/RT, this can be as easy as reading the /proc/rk files and looking at the minimum, maximum, and average utilization statistics for the reservation after an initial setup. A first rule of thumb is to look for average utilization within the same order of magnitude as the re-served utilization.