"Signal processing" is such an important job for computers that it shows up in popular culture--and the new Framewave open-source library fits squarely in the middle of the signal processing tasks programmers are tackling now.

In the movies, when computers aren't searching databases, propagating unlikely viruses, or tracing suspects' telephone calls, they're often seen sharpening fuzzy pictures, extracting faint conversations from background noise, or detecting messages hidden in snapshots of the family puppy. In this case, Hollywood is on-target, in that signal processing is as dramatic and even exciting in its technical realities as portrayed.

While signal processing operates on a wide range of data sources, multimedia currently present a particularly lively collection of problems:

• How can high-resolution movies or music be compressed to fit in a minimal bandwidth, but still be reconstructed in real-time with existing low-powered consumer devices?
• Is it possible for a computer to distinguish deterioration in a patient's heart function from normal variations?
• What kind of electronics makes a prosthetic ear or hand feasible?
• Are surveillance cameras on public streets capable of recognizing a fugitive from his photograph with, say, 75% of the accuracy of an experienced human spotter?
• Can automation infer a trend from stock market action quickly and precisely enough to profit?

These problems matter not just in narrow technical domains, but each one turns out to be at the edge of our current capabilities.

If you're working on such problems, you'll want to know about Framewave, which significantly expands those capabilities. The sections which follow explain Framewave and what it can do for you.

The Framewave library was launched on SourceForge in December, 2007. It’s described as a free and open-source collection of popular image and signal processing routines designed to accelerate application development, debugging, multi-threading and optimization on x86-class processor platforms, such as those from AMD.

The Framewave library is available for Linux, MacOS, Solaris and Windows, and is written in C++ and intrinsics. The MacOS release is new and welcome for Mac users. For Windows, even a cygwin-gcc build has been reported feasible, although I haven't yet tested it.

Framewave bundles 3,200 entry points formerly packaged in the AMD Performance Library, or APL. While the library includes a wide variety of facilities, it's particularly useful for programming codecs, image or audio editors, media players, or related projects. Framewave is aware of multicore processors, and in fact was written to aggressively exploit their multithreading capabilities.

Although sponsored by AMD, the Framewave project is very much an open-source venture, explains Advanced Micro Devices, saying, “While AMD will continue to participate in and contribute to the project, third-party developers are welcome and encouraged to implement all or part of the code base and/or to create derivative works."

Binary libraries of Framewave are available for most popular development platforms. I've chosen to work with source, which can be retrieved with svn checkout https://framewave.svn.sourceforge.net/svnroot/framewave/trunk FW_SourceForge. With the source retrieved, and all utilities in place, library generation is as easy as cd FW_SourceForge/Framewave; scons.

Framewave documentation prescribes ActivePython2.5.1 and SCons 0.97 or later, along with gcc 4.1.2 or later. I've used Python 2.5 and SCons 0.98 without difficulty, as well as gcc releases from 4.0.3 to 4.1.3. I haven't stressed the multi-processing functionality, especially with earlier compilers.

Although the generations went smoothly on the Unix hosts I tested, there's no satisfying test. It took me more hackery than is worth documenting here to put together executables based on the included UnitTest tree; I suspect the maintainers intend an easier solution, but I didn't find it documented. The 1.1 release certainly doesn't include any compelling demonstration executable that, for example, illustrates how clever Framewave coding can multiply reference performance by a factor of four, or even gives eye candy to whet programmers' appetites.

As "hot" as Framewave's domain is, the library was built for experts. It’s all about simplifying programming for those already actively engaged in signal processing projects. There are, for example, 44 basic transformations from one color model to another--"HLSToBGR", and so on--in several different variations to account for datum width.

Color transformations are right in the middle of Framewave's span of abstraction; at the lowest level, there are many functions for memory management and related programming "housekeeping" chores. Once a program adopts Framewave's data structures, high-level functions such as image shearing, JPEG compression, and H.264 decoding become accessible through an ANSI C style interface.

The reference pages truly are references, rather than tutorials. FilterLowpass, for example, is tersely labeled "filter with a low-pass kernel," without mentioning which low-pass kernel it implements. The documentation mentions enumerators including "Type of comparison operation" and "Type of CPU ...," without specifying the ranges of these variables. Frankly, for a lot of your work with Framewave, you’ll be looking at the source code.

Framewave represents an enormous value for those already facing tricky issues of instrumentation for performance measurement in a multicore environment or similar advanced matters.

The source code itself was developed according to a substantial Framewave Development Guide. The source is comfortingly consistent and clearly written.

Framewave's relation to multi-core processors is subtle, and deserves careful explanation. Signal processing is generally a CPU-intensive domain, one that profits from all the cycles it can get. As much as possible, signal processing will be done on modern equipment, which is likely to be multicore.

At the same time, signal processing presents an interesting mix of "parallelizability:" Many problems in the area admit significant parallelization, but others speed up little with more processors, often because of so-called "cache coherency" challenges. Framewave is largely neutral in all this; it's written in a way which makes it compatible with conventional threading implementations, but doesn't itself require threading. A few functions--Max() and Min() are examples--have no multi-threaded implementations because the maintainers decided they perform better when singly-threaded.

Perhaps the most interesting immediate connection between Framewave and multi-core architectures is at a different level: As signal processing becomes more mainstream, it's easy to imagine consumer applications dedicating a core or two to background signal processing tasks.

The overall distribution or threading of the application as a whole won't change, but it will take advantage of otherwise idle cores with special signal-processing chores. This couldn't have been done in the past, because multi-core processors were too rare, and even when available, didn't solve useful signal processing problems quickly enough. Algorithms and processors have both improved enough to put significant signal processing in the hands of the mass market.

Think, for example, of a wide range of Photoshop-like capabilities built into applications, with tasks returning after five seconds, rather than five minutes.

Framewave, then, doesn't aim to solve hard threading problems on its own, though it is written in a way that could expand to advanced distributed algorithms in the future. For now, it's enough to be engineered cleanly and compatibly with different threading models.

Signal processing programming will change significantly as the computing world moves to multi-core calculations. Framewave will be an important part of that change, and can greatly help certain specialized projects immediately.

Framewave is young, though, and several more months or, likely, years of development, and especially documentation, will likely pass before it becomes rewarding for a broad range of programmers involved in applying signal processing. Much of its value might consist in its demonstration of good coding practice for multi-core-savvy C++ programming.

Development in 2008 for many programmers looks unchanged from 1978 when 8086s were first released, and programming practice remains several steps away from taking full advantage of all that modern x86 and particularly multi-core x86 offer.

In the immediate future, Framewave is a library for experts. In the longer term, Framewave and libraries like it are likely to be vital underpinnings for the significant programming of the future.

Cameron Laird has published articles on technical topics for over a decade.