transform count
This is the number of transforms (FFT's) that baudline has calculated since program startup.

transforms/sec
This is the number of transforms per second that baudline is currently processing.  This includes pre-processing the waveform slice data, windowing it, FFT'ing it, turning it into log (dB) magnitude or phase space, and any screen or internal rendering of the graphical data.  As a benchmark reference, when iconified and set to a 2048 point FFT size, baudline can render 1300 transforms per seconds with a 450 MHz Pentium 2 and around 2000 transforms per second on a 650 MHz Pentium 3.

video FPS
This is how many video frames per second (FPS) that baudline is currently sustaining.  This is actually a function of many things.  FFT size, window dimensions, window visibility, backing store, number of channels active, CPU and video card performance and load all contribute heavily to this number.  Full screen 1280x1024, mono input with the startup -reset defaults, a 450 MHz Pentium II with a fast graphics card should be able to sustain a 70+ FPS rate.  For high baudline frame rates note that the performance of the video card's 2D hardware acceleration is as important as having a fast CPU. 

jump step
This parameter controls how jumpy the scrolling is which has a direct effect on the frame rate (FPS).  Baudline dynamically adjusts this number for maximum performance so it is normal for it bounce around.  The jump step parameter can be manually adjusted ±1 by pressing the widget buttons, the up/down arrow keys, and the mouse scroll wheel.  Holding down the Alt key while performing the increment action will change the jump step value by ±5 units.

stalls
This is a count of how many times the audio driver has been stalled.  Baudline automatically detects and restarts a stalled audio driver.  But still, stalling is bad as it causes gaps in the input or output stream.  A working system should not stall even under heavy load.  Stalls are a sign of major problems in the audio driver. 

potential drops
Also known as xruns or overruns.  This count is the number of instances that baudline has detected that the input or output stream has been interrupted.  This could have resulted in an audible gap or click.  The clear button clears this count to zero just like the trip odometer button in your automobile.  Dropping is caused by the CPU being too slow to handle the current load smoothly.  So in normal usage there should be no potential drops; if there is, reduce the overlap amount in the scroll control window. 

Moving X-Windows around in opaque mode on a Linux box is a sure way to cause potential drops.  This is because dragging an opaque window puts instantaneous demands on the CPU and video bandwidth.  In Linux the X Server runs at root priority, so the X task hogs the resources, something has to break, and results in potential drops as the slip point.  Note that if you run baudline as root, which is not recommended, then baudline schedules itself as a real-time task (SCHED_RR).  Running as a real-time task improves the smoothness of baudline's scrolling and it reduces the susceptibility to potential drops. 

The about window displays baudline's version number, a brief description, a hyper link to the baudline web page, and the distribution notice.