Sample Rates

Why does WriteLog display the Shared Mode sample rates in its Mixer Test panel?

Several WriteLog features merge audio streams from multiple input devices onto a single output device (or recording file). The two primary examples are the Headphones output can have its Left channel from one device, while its Right channel from another. When WriteLog merges audio in this way, it is required by the Windows API to arrange for the sample rates of the output Left and Right channels to match. But the input devices are running at their own sample rates, so conversions might be required. Continue reading “Sample Rates”

Optimize a Sound Board Setup

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.

Modes of Sound Board Support

This page based on a post I made to

As of Windows Vista, WriteLog had two very different schemes for supporting sound boards. As of version 11.24 there is a third. The pages in this blog are (almost) all about the third and most recently released scheme. The first two remain supported for legacy setups on Vista and later where all three Mixer setup modes can be accessed, but only the first is available on XP and earlier.

1. When WL first got sound board support (in the days of Windows 3.1 circa 1993, my how time flies), boards were expensive and the best way to support SO2R was to build special splitter cables and put the two rigs on the L and R channels of a single sound board. For all Windows versions from 3.1 through XP, the Windows-supported way to route audio through the PC involved using the old Win3.1 interface to flip mixer bits and manipulate mixer L/R controls. All versions of WriteLog when installed on XP and earlier support this, but with the caveat that the drivers provided with the boards actually allow flipping all those bits. WriteLog accomplishes L/R transmit switching by sourcing a monophonic signal and using the sound board mixer controls to adjust the Stereo Balance full Left and full Right. And it supports its “Echo Mic” by making the one-and-only sound board internally route its audio from its Mic input to its Line Out. This is the mode that is documented here, and also is the only mode where the old SoundBoardCheck does anything useful. Users can even coerce WriteLog to use this mixer-flipping method on Vista and later, but when WriteLog installs on Vista and later, I purposely arranged for it to hide this old capability because it uses old compatibility interfaces that modern sound board drivers don’t reliably support. If you really have to know: go into WriteLog’s Programs folder and find and run the file WlogSbControl.exe instead of WlogSbControlW6.exe. Notice that WlogSbControl.exe is all that is installed on XP and earlier:


2. As of Windows Vista, Microsoft published the Windows Core Audio API. On Vista and later, WL no longer plays with the mixer bits and levels–you have to use the Windows controls to set the levels. WlogSbControlW6.exe is what you get in Start menu, WriteLog V11, Sound Board Mixer Control. For station microphone input, you need a separate sound board (because, using this core audio, WL doesn’t try to manipulate a sound board’s internal audio routing). WriteLog accomplishes L/R switching of transmit audio by sourcing a stereo signal that has silence on L or R, as appropriate. Echo Mic is supported inside WL by reading the mic sound board channel and writing that sound–copied to the L or R channel as appropriate and with the other silent–to the “other” channel.


3. As of WriteLog 11.24 (the most recent). WriteLog can be configured to use a separate sound board per rig. SO2R support and mic switching, then, require a total of three sound devices on your PC. WL accomplishes L/R transmit audio switching by sourcing a monophonic sound (or Left-only) on the sound board connected to the rig.


WriteLog sound routing

With WriteLog set up to use a separate sound device per radio, and also configured for the station microphone and operator headphones, it has all the station audio routed through the PC and available for processing. WriteLog acts as a sort of crossbar audio switch.

WriteLog Audio Routing

The pink arrows show sound coming into WriteLog from receivers or the station mic. And the blue arrows show the sound coming out to either transmitters or to the operator headphones. The MMTTY digital decoder in the upper left  is shown to emphasize why WriteLog should not normally be configured to allocate the receiver audio channels exclusively. The shared access, however, does increase the latency in WriteLog’s routing of receiver audio to the operator headphones.

All the above in a fully configured shack is a rather complicated system. The WriteLog sound board mixer control has a Test button that brings up a dialog that enables you to exercise that internal audio crossbar switch.

Sound Board Mixer Test Button

If you compare the two pictures on this web page carefully, you can see that the buttons on this dialog correspond to the crossbar in the WriteLog drawing in the previous picture. A click on any button here turns on the corresponding switch in WriteLog’s cross bar. This dialog allows you to test all the possible cross points, including some that WriteLog would not otherwise use internally (e.g. routing the left receiver audio to the right transmitter.)

Use a separate sound device per radio

WriteLog version 11.24 introduces a configuration option to connect two radios to a single PC using a separate sound device for each. The original configuration option, connecting two radios to a single PC using the Left and Right channels of a single device, remains supported.

If you only have one radio connected to your WriteLog PC, then there is no important functionality difference between the original option and this one. The remainder of this page is to explain why you might want to use a separate sound device per radio on a single PC.

When you have multiple radios on a single PC, using a separate device per radio has more flexibility, and this entry is to describe those. Here is how you would wire the traditional configuration:

Only one sound device is needed and WriteLog supports SSB, CW and digital modes for both reception and transmission on two radios. Omitted from the drawing, but also supported by WriteLog, is the connection of a microphone to a sound board and routing its audio to either the Left or Right transmitter as you move WriteLog’s transmit focus. Depending on the Windows version, that microphone might (Vista and later) or might not (XP and earlier) need a separate sound board for WriteLog to support it properly.

Ground loop isolation transformers are recommended in both the receive and transmit directions, but are not shown in the diagrams.

Using the separate device per radio, you cable your radios this way:

It happens there are ham-oriented vendors that build devices that match the needed cable configuration. Purchasing a RIGBlaster, for example, removes the necessity of homebrewing cables. I have used WriteLog with the RIGBlaster Advantage, which has performance I can recommend for contesting operations. The only caveat is that the RIGBlaster Advantage receiver input is single channel monophonic, which means that any subreceiver audio your rig happens to produce is not available to WriteLog, and therefore cannot be routed to its headphones output. I have also tested with the RIGBlaster Blue, which I cannot recommend for contesting, mostly because I was unable to configure the bluetooth version to switch between transmit and receive faster than about 500 milliseconds.

Modern PCs can support several sound devices installed together, and that opens up the possibility for WriteLog to accomplish more sophisticated sound routing and recording, particularly if you add enough to cable up your station headphones and speakers as well, as in this picture.

To setup WriteLog to use such a setup, use its Start Menu entry named Sound Board Mixer Selection.

The cabling picture shows that, for a given sound board and rig, the receive and transmit would be wired respectively to the line in and line out and that is the recommended configuration. But its recommended only because that makes it easier for the operator to track what is connected to what. The in and out of all modern sound devices operate independently.

The Allocate exclusively button is there because of a performance subtlety. With exclusive allocation, the Windows operating system enables WriteLog to operate the devices involved with minimum latency (i.e. delay) between an incoming sound and an outgoing one. This is especially important for the “Echo Mic” feature, where your voice is routed through the PC. However, hams running digital operations commonly use a decoder program separate from WriteLog, like MMTTY or 2Tone, and even multiple decoder programs running in parallel on the same input concurrently, and WriteLog’s exclusive allocation would not allow those separate programs to open the device.

Even more subtle is that if you use a separate sound program in the transmit direction for AFSK, you might expect to need to turn off the Allocate exclusively selector for the corresponding rig’s transmit audio. It turns out that is usually not the case. Allocate exclusively can be turned on as long as WriteLog’s Echo Mic feature is turned off (because that removes WriteLog’s use of the transmit audio sound device), and, in fact, bringing up the RttyRite window corresponding to a given sound board will cause WriteLog to turn off its Echo Mic feature without the operator having to bring up that particular dialog control.

The Defaults button on this selector dialog sets the Allocate exclusively according to this “normal” configuration, with non-exclusive access to receiver audio, and exclusive (minimum latency) allocation of the other devices.