Portable Real-Time Applications

It is clear that transferring large amounts of data from
stage 2 to stage 3 is the bottleneck of the system. Writing into
the pipe, reading again and scanning each sample absorbs more CPU
time than every other operation. So, stages 2 and 3 must be
integrated into one program, because passing of data (44,100 values
per second) takes too much time. You might think integrating these
stages into one is a design flaw—it is not. I could have easily
renumbered stages and changed this article, but I preferred to show
you how cruel life in real time is to ingenuous software
designers.

For Stage 1, Tcl/Tk is a natural choice as a tool for
implementation of the first sub-problem. Many people have forgotten
that the GUI process in Tcl/Tk also has a textual standard output
which can be piped into the second process.

In Stages 2 and 3, the sound generator reads the textual
parameters from the GUI-process and computes the proper sound
signal from it in real time. Therefore, it should be written in C,
because it is the most critical sub-problem as far as real-time
constraints are concerned. As a side effect of sound generation,
the data needed for graphing the results will be written to
standard output and piped into the final stage of the
application.

Since Stage 4 outputs graphs of the results, it is also a
task well-suited for a tool like Tcl/Tk.

The user will notice only stages 1 and 4 of the pipeline,
because he can see each of them as a window and interact with them.
It is an interesting paradox that the seemingly important stages 1
and 4 are rather trivial to implement, given a tool like Tcl/Tk.
Stages 2 and 3, although mostly unnoticed, are the most challenging
sub-problems because of synchronization concepts in real time
(select or thread), real-time
constraints due to continuous sound emission and the different
handling of sound systems and all platform dependencies.

Concurrency of Development

We have already mentioned that one advantage of this pipeline
approach is splitting the development into largely independent
sub-tasks, which allows one programmer to work on each task
concurrently. Equally important is the fact that each stage could
also be implemented in different ways by different programmers. To
demonstrate this, we will look at three solutions to the stage 1
task:

Textual user interface on the command line

GUI with Tcl/Tk (Listings 1 and 2)

GUI with a Netscape browser and GNU AWK 3.1 as a
server (Listing 3, which is not printed but is included in the
archive file)

Also, we will look at three different implementations of
stage 4:

Textual output into a file

Graphical output of this data with GNUPLOT (Figure
5)

Graphical output with Tcl/Tk (Listing 5)

How Will It Sound?

Now that the design of the system is clear, it is time to
become more precise about the type of sound we want to produce.
Imagine a driven steel beam held pinned to fixed supports at the
bottom and top. When driving the beam from the side, the fixed
supports induce a membrane tension at finite deflections. This
leads to a hardening nonlinear stiffness for moderately large
deflections by a cubic term. At the beginning of this century, the
engineer Georg Duffing from Berlin, Germany was annoyed by this
kind of noise which came from vibrating machine parts. Such noise
is not only a nuisance, it also shortens the expected lifetime of
machine parts. Duffing found a simple nonlinear differential
equation which describes the behaviour of machine parts under
certain circumstances:

x'' + kx' + x3 = Bcos(t)

This oscillator is driven by a sinusoidal force on the right
of the equation (with magnitude B) and damped
by the parameter k on the left side of the
equation. So, there are only two free parameters in this driven
oscillator.

Figure 1. Changing parameters k (damping) and
B (forcing) will move the oscillator in or out
of a chaotic regime (see page 11, Thompson/Stewart).

In Figure 3, you can see a short wave form originating from
such a sound machine. Unlike Duffing, you can simulate the noise
production with your computer by varying the parameters with a GUI
such as the one shown in Figures 1 and 2. You should expect that
varying parameter B on the right axis of
figure 1 influences just the volume of the noise. In fact, by
pushing B to its minimal position 0, you can
actually switch off the noise. When pushing parameter
B to its maximum, noise will not only become
louder, it will also change the main frequency but not in a
continuous and monotonic way. This strange behaviour of changing
frequency along with loudness does not occur in linear oscillators.
In 1980, Ueda published a systematic look at the points in the
plane opened up by the parameters B and
k in Figure 1. By computer simulation, he
found areas where the oscillator emits chaotic sounds. These
results are summarized in Thompson and Stewart's book (see
Resources).

Why is it so hard to compute these wave forms? After all, a
formula to be evaluated for each time instant should be all that is
needed; however, there is no such analytical function. When in
trouble, engineers often fall back on simple approximations. We
will do so with a technique called Finite Differencing (see
Resources) which gives us a one-line calculation at each time
instant (Listing 4).