# 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.

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)

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.

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).

## Trending Topics

Non-Linux FOSS: Snk | Feb 08, 2016 |

diff -u: What's New in Kernel Development | Feb 05, 2016 |

What's New in 3D Printing, Part III: the Software | Feb 04, 2016 |

Poppins | Feb 03, 2016 |

Giving Silos Their Due | Feb 02, 2016 |

February 2016 Issue of Linux Journal | Feb 01, 2016 |