Audio setup.
At the Remote Site
To deliver audio to connected control sites, the DVK (digital voice keyer) at remote site must be Windows Sound Card. Otherwise, control sites will be unable to connect for remote audio at all. Secondly, the remote site must have its WriteLog Sound Board Mixer control set up. The Sound Board Mixer control can be set to either of its modes, One-Device-Per-Radio or Two-Radios-on-One-Device. Review the WriteLog help file for details on how to choose between those modes. If you have only one radio at the remote, there is no functionality difference between the two settings. With two radios at the remote use One-Device-Per-Radio for a setup with a separate Windows Recording device attached to each radio. Use Two-Radios-on-One-Device for a single stereo Windows Recording device recording two radios through a Y breakout cable, the L channel for one radio and R for the other.
At the Control Site
To hear receiver audio at the control site, you select a control site playback device from the Start RX selections. To send mic audio from the control site to the remote, select a control site recording device from Start Mic. Its not flowing yet. Next “Connect audio” which, if the login at the remote succeeds, the two Start buttons are enabled. Start RX for headphone audio and Start Mic to send mic audio.
The exclusive allocation buttons set the Windows exclusive allocation for RX incoming or mic outgoing. It is recommended to leave the exclusive allocation off so that other Windows applications can make sounds in your headphones while you are involved in remote control. Exclusive allocation is supposed to provide less latency. “Supposed to” is in the hands of the audio device manufacturer’s device driver. For the microphone side, I have found the exclusive setting to be a crap shoot, depending on the device driver. For some devices it works better than non-exclusive but for others, it doesn’t work at all. Exclusive allocation also enables lower latency because the sound card deals in much smaller audio snippets in exclusive mode than shared. Once you are routing audio over the internet, adding a couple of dozen milliseconds of latency for non exclusive access will be small contribution to the total end-to-end.
Playback buffer msec
This is a critical tuning parameter. For incoming RX audio, the control site maintains a buffer of up to the length selected in order to compensate for jitter in the arrival time of audio packets. Smaller numbers give smaller latency (delay from the radio to your ears) but also increase the risk of distortion (usually clicks and pops) if internet traffic delays a packet out of your selected interval. The recommended procedure for setting this is to start about 100 msec and listen for “drop outs.” A drop out will often start with a click or pop, and, for TCP audio, will be followed by about 1 second of audio with the pitch raised slightly. Using UDP mode also has drop outs, but no pitch shifts. Drop outs are caused by time jitter in the delivery of internet packets to the control site. Increase the Playback Length in 20msec increments (use Disconnect and then Start Rx to make a change.) Stop increasing the setting when you hear few enough, or no drop outs. Going higher will increase the delay (latency) of the audio in your headphones at the control site but won’t improve the quality. In a steady state, where the across-the-internet latency remains constant, WriteLog maintains its buffering at about half the length of this Playback buffer setting. With exclusive allocation turned off, the Windows sound driver maintains more buffering which means a lower setting here should work for non-exclusive than is required for an exclusive allocation. It is recommended to leave the exclusive check boxes off because the lower latency possible in exclusive mode is swamped by the latency of most internet connections, while also preventing other applications from using the devices at the control site.
Far lower numbers, like 100msec or less, will work if the control site is on a wired local ethernet switch with the remote site. A wifi network in the path will require higher numbers. Across the internet, expect to use 180msec or even higher.
There is an analogous tuning parameter for mic audio, but its at the remote site. Its labeled the same way, Playback buffer, in the One-Device-Per-Radio mode under the Test button, or in the Two-Radios-On-One-Device main screen. Its trickier to test the mic audio for dropouts, but it is reasonable to assume it is affected in the same way as RX audio. Once you have an acceptable Playback buffer length for RX audio, per the screen shot above, then use the same number on the remote site Sound Board Mixer Control.
The correspondence between the audio devices at the remote, and those at the control site are these:
The control site RX device hears the Left radio in the left ear, and the Right in the other. control site Mic audio is delivered to one Xmtr at a time, depending on the TX focus in WriteLog (at the control site!)
The”One Device Per Radio” setup is shown above.
The “Two radios on one Device” mode at the remote is also supported like this.
Regardless of that mode at the remote, the control setup is the same. At the remote site, the devices under “Operator” for Mic and headphones are released by WriteLog when an incoming control site connects (and they are released before the control site allocates its RX and Mic devices so in localhost mode, it is OK to put the same devices in the two screens shown above.)
Compression Settings
The Compression settings… button brings up this dialog:
The settings for the two directions are separate. RX audio flows from remote to control, and the mic audio in the other direction.
The bits/sample settings are 16 (which is CDROM quality), 12 (which is generally more than adequate) and 8 (WriteLog uses CCITT G.711 mu-law standard audio encoding in its 8 bit setting.) Higher numbers of samples require more internet bandwidth. Lowering the high cutoff settings reduces the bandwidth requirement, but of course they reduce fidelity.
WriteLog does not use the cutoff frequencies exactly as entered, as it might have to choose a higher frequency than you enter. In order to keep its resampling calculation manageable, WriteLog decimates sampling on your RX audio sound device (at the remote) or Mic audio sound device (at the control site) by an integer factor that results in an integer number of samples per second. For example, reducing 44100Hz sampling using a 3000Hz cutoff setting actually results in a 3150Hz cutoff because the integer 14 exactly divides into 44100 to give 3150 while no other integer division of 44100 results in an integer above 3000.
The Use TCP only check button, when on, prevents WriteLog from using the more tolerant UDP protocol. (UDP audio is supported in beginning in WriteLog version 12.34.) As a rule of thumb, leave this button on UDP unless you are willing to pay a performance price to keep your audio safe from internet eavesdropping.
- UDP for audio streaming tolerates internet pauses and timing jitter better. You’ll hear a difference on RX audio, or your mic’d voice on SSB transmission, if the internet path to your remote station has drop outs or changes in latency. UDP will have fewer audible distortions.
- WriteLog’s UDP audio is not encrypted in either direction, while in TCP mode, audio is. This means that eavesdroppers along the internet (for example, someone on the same wifi network at your local coffee shop) could decode the audio in WriteLog’s UDP packets. WriteLog’s TCP traffic is a much more difficult cryptographic problem to eavesdrop.
- Network administrators can selectively block and enable UDP and/or TCP traffic and in both directions. WriteLog requires a TCP connection from the control site to the remote, which is why you must open any firewall at the remote site to accept incoming connections on three ports (defaulting to numbers 6555, 6556 and 6557.) Writelog will also use UDP routes if it can find them—each direction is separately configured—except if you check this TCP only button.
An internet posting on the details of UDP versus TCP is here.
Once you complete “Connect audio,” WriteLog knows the sample rates on the sound devices and displays the resulting cutoff and bandwidth requirements as shown above. (The Kbps label indicates units of 1000 bits per second.) The RX audio is always produced in stereo, and the mic audio is always sent to the remote in mono, which is why, all other settings being the same, the RX audio requires twice the bandwidth of the microphone.
The UDP indicators come on if WriteLog is using UDP in that direction. Because network administrators can separately block UDP in either direction, it is possible for UDP to work in one direction but not the other, so there are separate indicators. WriteLog silently falls back to TCP if the UDP path fails.
If you’re running CW only, and if your internet connection is slow, it would pay to leave the Mic audio off, and to reduce the RX cutoff even as low as 1000Hz. SSB won’t be copiable, but CW with a low beat note will be.
Hint: with WriteLog’s exclusive setting turned off, WriteLog must use the “Default Format” in the “Advanced” tab in the Windows control panel Recording Device (for capturing audio) or the control panel Playback Device (for audio output.) You will make Writelog work much harder if you don’t use Windows Control Panel to set those two to match for a pair of devices WriteLog Remote Control connects. That is, if the Windows Default Format for the two devices, the RX audio device capture at the remote, and the RX device for the Control Site Setup, is to different sample rates, then WriteLog has to convert one to the other. For historical reasons, there are two rates in common use that require a 160:147 resampling. 44100Hz is used on audio CDs. Later, 48000Hz became the much more commonly used rate, and is used for the audio channel on DVDs. WriteLog will silently do such a conversion, but you’ll pay for the extra CPU and latency required. With exclusive turned on, WriteLog can choose a rate among those supported by the device, but that is not necessarily a good solution because the playback side of WriteLog (the destination for the audio) cannot dictate back upstream to the recording side (the source of the audio) what rate should be used to capture.