# 5.5. Computation Issues

TiMidity can fall behind in computing data to send out to the sound driver, and then there are dropouts in the music. TiMidity tries to anticipate the possibility of a dropout by monitoring the state of its output buffer and those of the sound driver, and when there is not much in the buffers, it tries to catch up by minimising the calculations it has to do: it uses a cruder interpolation routine in resampling, stops doing extra echo and detuned notes for reverb and chorus effects, and starts terminating notes early, or even skipping notes altogether. So, depending on midi song, patchset, how fast your system is, even if you don't hear dropouts, you will notice a loss in quality as TiMidity gets busier. KMidi's front panel lights give some picture of how desperate TiMidity is becoming in its effort to keep the music playing. (Signs of desperation: the buffer led goes from healthy greenish to busy orangeish, the interpolation led turns off (meaning linear interpolation is being used for resampling), the echo led goes off, or the detuning led goes off (meaning no extra echo or detuned notes are being played).

Monitoring the output buffer involves calling the sound driver to find out how much data it has buffered up. I know how to do this for Hannu Savolainen's OSS driver (Linux and some other systems), perhaps for older Suns (it used to work), but not for other drivers.

You can lighten TiMidity's computational burden by various maneuvers: (1) reduce the permitted polyphony (spin box on lower panel), (2) press off the "eff" button, (3) choose cheaper resampling interpolation (one of the checkboxes on the upper panel further to the left), (4) turn off echo, detuning, or stereo using the left three checkboxes on the lower panel, (5) choose the "dry" setting on the Reverb menu. Of course, there is generally some attendant loss in quality. Having the "filt" button on doesn't cost anything unless you've also chosen the "cspline+filter" interpolation option.