Notes about performance in audio applications
=============================================
You are probably reading this file because of an error message displayed on
console. The purpose of this document is to explain what the following error
messages mean and how to fix the situation:
"OSS warning: Application caused too much output underrun errors on audio device #N."
"OSS warning: Application caused too much recording overrun errors on audio device #N."
*******************************************************************************
* First of all you should understand that the above messages are not *
* caused by a bug in OSS or a problem in OSS configuration. *
* OSS just tells that the application you are trying to use does not work *
* correctly. In some cases this happens because the application is buggy and *
* sometimes your system/environment just doesn't meet the requirements of *
* this particular application. *
* *
* IN ANY CASE THE PROBLEM IS SOMETHING THAT IS BEYOND CONTROL OF OSS DRIVER *
* AND 4FRONT TECHNOLOGIES. *
* *
* For the above reason trying to fix the problem by changing OSS settings is *
* completely useless. Such changes will not make any difference. *
*******************************************************************************
You can get rid of these messages by adding the following line to options.cfg
(in the directory you installed OSS). However this change will not fix
the actual problem. It just prevents OSS from telling about it.
be_quiet=1
About real time requirements in audio applications
--------------------------------------------------
During audio playback/recording the device is consuming/producing audio data
at fixed rate. If the application is not able to work at least at the same
rate then an overrun/underrun error will occur. The result is that there
are clicks or pauses in sound. The sound may even be completely garbled
(noise). There is no way around this timing requirement. If the
application cannot meet this it will fail, period.
How to fix it?
--------------
Just in very rare cases the problem is caused by something in the system/environment. In most cases the reason is in the application design. If you are writing
the application yourself then proceed with the rest of this document. We are
trying to explain some common problems and how to avoid them.
IF YOU ARE USING AN APPLICATION WRITTEN BY SOMEONE ELSE then take a look at
the documentation provided with it. If they don't give the answer you should
contact the author of the application. Or try to find another application
that does the same thing. Many free applications simply don't work and they
may even be very far from working.
Unfortunately nothing can prevent people from making broken software available
from their ftp/web site (or even through some public sites).
The rest of this document doesn't contain anything that is useful for end
users. Also 4Front Technologies cannot help you since this really is _NOT_
an OSS problem.
Performance problems during audio playback
------------------------------------------
An playback underrun happens if the device plays all the data in the
buffer before the application writes more (actually this is a somewhat
simplified description). Normally this is not a problem since most
applications are able to keep the buffer full all the time. Actually they
spend most of time in waiting for space to bee freed in the buffer.
However sometimes the buffer becomes empty when the application fails to
write more data quickly enough. This may happen rarely with any application
simply because there are some high priority processes taking all the available
CPU time or disk I/O bandwidth. The result of a random underrun is just
a click, short pause or a repeated fragment of earlier played sound. However
there are situations when an application completely fails to meet the real time
requirements described above. There are several possible reasons:
1) The application performs heavy computations that require a faster CPU than
you have.
This is not a common reason any more with todays 500MHz and faster systems.
They almost certainly can perform anything you like to do (except perhaps
doing speech recognition using shell scripts).
This was the main problem in the good old 386/486 days (does anybody remember
them?). Just a simple 4 channel .MOD player required more than 386/25 power
when playing at 44100 Hz sampling rate (22050 was OK). However there will
always be applications that require more power than available even in the
fastest CPUs. Csound (an computer music package) is a good example of this.
After it becomes possible to play all the sample score files distributed with
Csound in real time somebody will write a more complex one.
In practice applications doing audio compression/decompression such as
MPEG (MP2, MP3) players are good examples of this. A useful way to identify
these kinds of applications is using a system monitoring tool (such as top) to
check the CPU consumption of the application. Applications requiring more
than 80% to 90% of the CPU time (of a single processor in SMP systems) are
almost certain to have problems because of high processing power
requirements.
However some applications seem to use tricks to make their CPU consumption look
smaller than they should. So they may still be suicide candidates even their
CPU usage seems to be rather low.
It's a common mistake to think that there are tricks to make pathologically too
demanding applications to work better. Unfortunately methods like increasing
applications priority (or making it a real time task) will not help. The application
is competing just with itself. Also increasing the audio buffer size will not help
in this case (in addition it's not possible).
The only workaround with this kind of applications is decreasing the sampling rate
(if possible). This will decrease the CPU consumption proportionally (unless
the application belongs to the last group (below)). Of cause upgrading the CPU
could be a solution but sometimes the new CPU would need to be 20 times faster
than the current one (hard to know this before trying).
2) I have a dual PPro/NNN system. It's certainly fast enough
This may be disappointing but the above claim is not necessarily true. In fact it's
rather rarely correct. First of all most applications are able to use just one
CPU at time. Having a dual processor system will not show any improvement. It may
help only by having another CPU for serving the competing processes.
Another disappointment is that performance of PPro is actually not so good in all
applications. For example applications performing "resampling" and mixing of
several signals work significantly faster on P166MMX than on any PPro CPU.
3) There are too much other processes running in the system
There will be problems with audio applications after the system load raises above
80% to 90%. The load shown by monitoring tools is an average over rather long
time interval. It doesn't show if the instantneous load is sometimes too
high.
One workaround to problems caused by other processes is increasing it's priority
(in way or other).
4) Disk performance problems
Sometimes the disk drive where an audio file is stored is too highly loaded.
This causes too long wait times to the application playing the file. The workarounds
are eliminating the competing disk load, moving the file somewhere else or
getting a faster disk. Also using a more intelligent player (with application
level buffering) may help.
IDE disks are more likely to cause problems than SCSI ones. However todays
UDMA capable IDE drives are decresing the difference.
Earlier single speed CD-ROM drives were causing problems but todays 20X drives
are certainly fast enough. Playing files directly from an NFS partition may also cause
problems.
5) Network bottlenecks
Actually this kind of problems are not bugs but features. Internet is currently
not capable to guarantee any bandwidth to an audio stream (this is sometimes true
with Ethernet too). When the network is overloaded the bandwidth may drop to
just few percents of normal. This is just reality and we need to be ready to
live with it.
However an application needs to be able to live with these realities. The
techniques to be used depend on the application.
ISDN, ATM and some other kind of network connections are able to deliver the
promised bandwidth. However there is another difficulty that may cause problems.
There is practically always a minor error in the sample rate produced by soundcards.
Even the audio device is set to 8kHz operation the actual sampling rate may be
say 0.0001% smaller or higher than this. This means that the audio device may require
data faster than the network connection gives it. This drift will cause buffer
underruns or cause dropouts of network data sooner or later. So the application
needs to be ready to handle this error for exaple by dropping or duplicating
samples at proper rate.
6) Badly behaving devices or drivers (very very very rare)
Sometimes even a poorly implemented device or driver may prevent an audio
application from getting enough CPU time (however in this case it's CPU
requirements should be fairly high). This may happen with (old) slow ISA
devices which use PIO for moving lot of data between memory and the device.
Poorly designed device drivers may spend significant amounts of CPU time
while waiting for device events in a wrong way.
7) Hickup under X11
One very common reason to this kind of problems are old (unaccelerated)
graphics (VGA/SVGA) cards used with X11. If moving the mouse pointer
or a window causes hickup it's the right time to get a true graphics card
(upgrading to the latest X11 version may help too).
8) Recording and playback using two separate soundcards at the same time
will _NOT_ work. You cannot write a multitrack recorder using multiple
soundcards. You even cannot record using one soundcard and playback the result
with another. Two soundcards simply just don't work exactly at the same rate.
There may be exceptions but in general finding two exactly matching cards
is impossible. However you may be able to do this if the time required is very
short (just couple of seconds).
About recording overrun problems
================================
Audio recording is very similar operation than playback so everything said
earlier is valid. However there are some additional problems:
1) Writing data to disk takes more time than reading
In general it takes longer time to write data to disk than reading it. In particular
writing to a regular file requires more time due to space allocation tasks. OTOH
intelligent disk cacheing methods will decrease the required time. This is very
much operating system dependent.
2) Recording overruns are more annoying than playback underruns
A recording overrun means that you will permanently lose some of the recorded
sound. OSS will discard the oldest data in the buffer when an overrun occurs.
In playback you can possibly retry the operation (depending on the application).
3) Buffer flush policy in Linux
Linux tries to minimize disk I/O by delaying actual writes as long as possible.
The data written to disk files will be held in the main memory (buffers) until
the update daemon forces it to disk or somebody executes sync command (or
system call). In this way it's possible to avoid completely writing many temporary
files to disk because they are deleted before the update daemon attacks to them.
Unfortunately this makes it difficult to maintain sustained writes to disk files.
At the time update runs (every 30 seconds or so) the recording application wil
suspend for relatively long time until the update operation completes.
If the application keeps blocked too long time the buffer will overflow. This
is more likely to happen with IDE than with SCSI disks.
This problem can probably be solved only by using special application level
buffering. Try another application if you are having problems with the current
one.
Full duplex problems
--------------------
Full duplex (simultaneous recording and playback) may make performance problems
more difficult since it usually means that two tasks are competing about
the same resources. However the possible workarounds given above may work with
full duplex applications too.