From the WriteLog help file, there are these four entries, all in WRITELOG.INI the [WlSound] section that affect WriteLog’s behavior when copying a sound from one of its input devices to one of its outputs.
EchoMicBufferMsec specifies how much time delay the echo microphone feature uses. For some systems,
longer delay can reduce distortion caused by too much CPU load.
EchoMicBufferMaxMsec specifies the maximum msec delay allowed. WriteLog uses
EchoMicBufferMsec plus 25 msec, or this setting, whichever is longer.
EchoMicRenderMultiple specifies a multiplier on the rendering (output) audio device base
software period. Testing indicates that operating at the base period itself distorts audio on
some devices, so the default is 2. Valid values are 1 through 10. Only applies to exclusively allocated devices.
EchoMicCaptureMultiple specifies a multiplier on the capture (input microphone) audio device base
software period. Testing indicates that operating at the base period itself is usually OK
so the default is 1. Valid values are 1 through 10. Making it higher increases latency. Only applies to exclusively allocated devices.
These settings deserve a more detailed explanation.
For each of the four above settings, WriteLog ships with no setting in writelog.ini and attempts to use a reasonable default. Users that like to tune their systems will need more information, as will users that have trouble especially with WriteLog’s Echo Mic feature outputting distorted audio or a “growling” sound, or, to use the word in the Microsoft Core Audio API documentation, “glitches.” These issues can happen when the output device is not fed as much sound data as it needs in order to produce a continuous high quality sound at its output.
This is the number of milliseconds of audio WriteLog captures from its input before it starts the render device (the output). Making this number bigger gives the capture process a bigger head start and therefore reduces the chance for glitches, but every msec here adds to the latency, the delay between the input sound and its output. The internal WriteLog audio routing where this matters includes the Echo Mic function (where microphone audio is copied live to the rig), and also in Headphone audio (where receiver audio is copied live to the operator headphones.)
You should almost never set this INI entry as it is more of a debug entry. It exists because the actual sound sampling rate of two different sound devices may be set to exactly the same number, but in reality their internal clocks are not perfectly in sync. If the capture side is adding data slightly faster than the render side is consuming it, then WriteLog has to notice this situation and take corrective action. This setting determines how far it lets the render get behind the capture before taking such action
When running in exclusive mode (and only then–not in shared mode), the Windows device driver for the device has an internal sound buffer of a manufacturer-determined size. The device deals in sound snippets of this length and never smaller or larger. In order to achieve minimum latency, this setting should 1, and WriteLog arranges for sending the driver snippets of this minimum length. However, some devices simply do not work reliably when sent this minimum sized snippet. Setting this number higher causes WriteLog to send larger snippets, which can reduce glitches, but also increases the latency
This setting has essentially the same explanation as the previous setting,
EchoMicRenderMultiple, but changes the way WriteLog interacts with a capture device. Some capture devices don’t reliably work with minimum-sized snippets and this setting instructs WriteLog to use large ones.
When WriteLog’s Sound Board Mixer control’s Test button is pressed, it reads the above INI entries. You can edit WRITELOG.INI, click that Test button and listen the the results as you click on the various check boxes on that dialog. You can then Cancel the test dialog, change and save WRITELOG.INI again, and then click the Test button again without existing the Mixer panel.