LineIn plugin for Winamp 2/5 Documentation - Performance


Up  |  Previous  |  Next  |  Down

Minimizing the delay

The problem

Winamp is a plugin based audio(/multimedia) program that works by forwarding audio data from intput plugins to VIS plugins, DSP plugins and output plugins, below is a picture of how it's done with my plugin (roughly, actually the DSP plugin returns the modified data to the input plugin):
Winamp plugin structure
As you can see a DSP plugin will introduce a delay because it is put between the output and input plugin. Unfortunately that's not the biggest problem, it's possible to hardly notice any difference (in delay) between using a DSP plugin and not using a DSP plugin. The main problem is the plugin architecture itself, because the input plugin first has to fill a buffer before it can forward it.

The solution

It will never be possible to eliminate the delay, but... you can minimize it.

Tuning the output plugin

Yes, this can actually have an effect on the delay, a very big effect even, most people don't realize it, but an untuned output plugin is one of the biggest causes of delays! In simple tests - I played a tone in an cooledit, sent it through Virtual Audio Cable and paused it when I heard the signal - I easily achieved 2 times as small a delay, 0.3 seconds instead of 0.7).
The output plugin can be tuned, this can be done by using the out(pre)buflen options of my plugin, or by tuning the plugin directly through its configuration dialog.
The out(pre)buflen options probably don't work with all output plugins, so you may want to try atleast both the waveOut and the DirectSound plugin (which is advisable anyhow). But if the options work they should specify the length of the buffer the output plugin uses and they should affect the maximum latency of the output plugin, in theory (I have no idea wether there are actually output plugins that support those options). The outprebuflen length must always be less than or equal to the outbuflen.
Configuring the output plugin through its configuration dialog is very plugin specific, but in general big buffers mean big delays.
NOTE: The waveOut API is usually preferable to the DirectSound API on Windows 9x/ME, for NT/2000/XP it's the other way around (in fact on my system the waveOut API always hangs my XP system). But this hugely depends on your drivers, so experiment a bit to see what works best on your system.
waveOut plugin
Try to lower the main buffer, the total number of buffers and the maximum and minimum sizes of buffers, but if you get undesired results, don't hesitate to play with the values until you like it (I'm not sure about which actions have the best effect).
DirectSound plugin
Try to lower the main buffer size, the Directsound polling delay and the Directsound block size. In this case it's also advisable to play with the settings until you get nice results (since I'm also in this case unsure about the precise effect of the different settings).
Some (recent) version of the DirectSound plugin has been reported by someone to provide much lower latencies than the waveOut equivalents, but "your mileage may vary".
Low-latency waveOut plugin
This is my own output plugin, created to work with my LineIn plugin, in order to minimize the delay as much as possible. The plugin works by forwarding a buffer to the driver as soon as it receives one. The plugin can be downloaded here.
ASIO output plugin
If your soundcard supports ASIO (usually only high-end cards) this will (at least theoretically) provide the lowest latency possible. The plugin can probably be found by searching on Google or in the HydrogenAudio forums.
NOTE: There is a driver available that will provide ASIO support for just about any soundcard, see http://michael.tippach.bei.t-online.de/asio4all/.
NOTE2: The ASIO Winamp plugin can be found at http://otachan.com/.
Nullsoft NULL Output plugin
If you don't need Winamp's output (if you're only using Winamp for visualizations for example) then you should consider using Nullsoft's NULL Output plugin. This output plugin doesn't do anything with the sound, which makes Winamp perform really well, and if you can get the sound to the speakers through some other means you may be able to get really good synchronization. To get the sound to the speakers without going through Winamp you can either completely by-pass your computer or unmute your input device for playback (see the section about setting up your volume settings Basics).

Buffer sizes

The most obvious solution is simply to decrease the buffersize, that way the input plugin will be able to forward data sooner and thus create a smaller delay.
There is one straightforward option to control the buffersize and that is bufsize. The bufsize option lets you specify the buffer size used by my plugin in bytes, this allows you to set the buffersize as low as 576 bytes (upto v1.42, after that even smaller sizes are possible), this size was based on a wrong assumption I once made, but experience has shown that it works. So to get you started:
Unfortunately this will probably cause a lot of skips, since the buffers will be filled very quickly and the plugin won't have time to catch up. That's where the option numbuffers comes in, this lets you specify how many buffers my plugin will use. So better would be (and often sufficient):
The maximum number of buffers used to be 50, is 100 in v1.42 and 1000 for later versions.
This is about as far as you can go with tweaking the buffer size.
Some pointers on using the bufsize option:

Reducing the time contained in one buffer

A clever way to reduce the delay is to simply input the sound at a higher quality and thereby reducing the time contained in one buffer. Some pointers:

Evading the problem

Of course a delay is never welcome, but if you can't get it small enough it's often possible to evade the problem, by using Winamp's sound output as well as its VIS, those will be much better synchronised than the source and the VIS.

VIS performance

I can be quite short about this. If you have the delay minimized, then all you need to do is start your favourite VIS plugin.
The only problem is that your VIS plugin might not like the settings you specified while going for that extra 0.01 second delay reduction, so you might have to play a little with the settings before you find something that satisfies you.
The optimal buffer size for VIS plugins should be 576 * NCH * (BPS/8), which translates into 576 samples, which you can specify directly, with the option: Or you can calculate it yourself and then you would use something like this: Although 576 samples should be the optimal setting, nobody is telling you that you can't use a different setting, it just won't work (well) with all plugins.

Up  |  Previous  |  Next  |  Down


To contact me, please mail to: th.v.d.gronde@hccnet.nl
I hope you'll enjoy my program(s).