Speak Freely for Windows

Bugs, features, and frequently-asked questions

I have a high-bandwidth connection to the Internet. Why do I get pauses and lost sound?
Unlike file transfers, transmitting intelligible audio requires not only adequate bandwidth but consistent delivery time. If one packet of sound takes a tenth of a second to arrive, the next two seconds, and the third half a second, not only will be there an audible pause but they'll be received and played out of order.

Network congestion and moment-to-moment re-routing can cause precisely this kind of inconsistent delivery time. If you're using a public network, there's nothing you can do other than try again later when there may be less traffic. Remember, the Internet was never intended to transmit real-time data such as audio; it's a miracle it works as well as it does.

When I send, nobody can hear me / I can't hear anybody else.
(The following was contributed by John Deters, jad@dsddhc.com). For those of you who aren't particularily familiar with Windows audio hardware but would like to use Speak Freely, here are some hints that might help get you started.

First, does your sound card play regular Windows sounds? When you start Windows, do you hear the "Ta-Da"? If not, make sure your speakers are plugged in to the "speaker" or "output" jack coming from your sound card. While you're at it, make sure your microphone is plugged into the "mic in" jack. If there is a volume knob on your sound card, make sure it's turned up. If your speakers have a power supply (such as batteries or a power transformer) make sure you have power, such as fresh batteries or the transformer is plugged into a live outlet. Make sure your speakers are turned on. You may need to refer to your sound card or speaker's documentation to get it set up correctly.

Some sound cards come with the microphone input not "turned on". What this means is that your sound card will not "listen" to your microphone until you tell it to. Included with your sound card was (probably) a "Mixer" appliation (if not, there may be a volume control application in your Accessories group.) Double click the Mixer to start it. With Sound Blaster cards, the mixer appears as columns of sliding volume knobs. Your sound card may have come with a different mixer.

If there is a volume control labeled "Microphone", this refers to how much of the sound from the microphone input will come out through your speakers. For now, turn it on (by checking the box or whatever) and set the volume to the same level as the volume control marked "Wave". If you're not sure, just turn it all the way up (you can always turn it down later). Make sure the switch on your microphone is turned on, and tap on it or talk in it. Do you hear yourself? If not, you need to find the input side of the mixer.

Hunt around for a menu option or button called "Recording Controls". When you select it, you'll see a similar looking screen that lists all of the inputs to your system. Turn the microphone input on by clicking the box, and if there is a "gain", set it to its maximum setting. Now, try tapping on the microphone. You should now hear the tapping coming from your speakers. Speak into the microphone, and compare the level of sound from your voice to that of the other sounds in your system.

You want your voice to come out about the same loudness as the "ta-da", and you want it to be intelligible. You may need to adjust the gain downward a bit, or find the correct place to hold your microphone. Some microphones need to be held almost to your lips, while others meant for mounting on your monitor need to be a foot away from your face before you sound good. Experiment with this for a while until the sound coming out of your speakers sounds good to you.

Once you have the microphone gain set, you should return to the output side of your mixer by finding the menu option or button labeled "Volume" or "Output". It might have opened a second window called "Recording Control" or "Input" that you will need to close. Once you get back there, you will probably want to turn the microphone OFF by un-checking the box. This will keep your side of the conversation off of your speaker, preventing nasty feedback squeals. When you've done that, you won't hear anything else from your microphone coming out your speaker, but you now know that your microphone is set up for recording your voice. (Special note to headphone users: if you use headphones, leave the microphone ON. It will help your voice sound better to you, and your conversations will sound more natural. You might wish to adjust the microphone volume setting.)

For a good test, use the "Sound Recorder" program found in your "Accessories" group. You should be able to click on the "Record" dot, say something, click on stop, then rewind, then the play arrow, and hear yourself.

Once your audio hardware is correctly set up and working to your satisfaction, you will probably find that Speak Freely now works surprisingly well. You can use the local loopback facility to verify correct operation with Speak Freely, then proceed to experimenting with an echo server.

My machine hangs as soon as I try to transmit.
This is usually the result of failing to set a compression mode appropriate for the speed of your Internet connection. What should happen in this case is that sound that can't be sent in time is just discarded, but some implementations of WINSOCK seem to hang the machine when a program tries to send data faster than the network can accept it. In many cases (assuming you have a fast enough computer), setting Options/GSM Compression will cure the problem.

I tried to call you and nobody answered.
Tens of thousands of people have downloaded Speak Freely, and the first thing a depressingly large percentage of them do is immediately try to call me to "see if it works". If I allowed all these calls to interrupt me, development on Speak Freely (and everything else) would immediately cease. So while I occasionally accept calls, until and unless people become more considerate of my time, I mute the speaker whenever I'm doing serious work. Use one of the echo servers for testing; that way you won't bother total strangers with unsolicited calls.

My dial-up Internet connection gives me a different host name and IP address every time I connect. How can other people find me when I'm on-line?
Publish your E-mail address on a Look Who's Listening server. People who wish to call you can look you up on the server, see if you're currently connected and, if so, connect to the address for this session. You can use the same procedure to locate other users with dial-up connections. Since your E-mail address is unique and does not change from session to session, it allows others to find you regardless of how you are currently connected to the Internet.

Why do I connect to a machine (like furry.zoo.org) instead of a user (like panda@fuzzy.zoo.org)?
Because the audio hardware belongs to the machine, not the user. Think of it like a house with a single telephone; there may be several people living there, but they all share the same phone number and only one can use the telephone at a time. Your host name or IP address is just like a telephone number, and your computer the telephone. To find what host name a given user is connected to at the moment, look up their E-mail address on a Look Who's Listening server.

Is there / when will there be a Macintosh version?
As soon as somebody makes one. I don't have either the knowledge nor the hardware to port Speak Freely to the Macintosh myself, but it would be a relatively straightforward project for a Mac developer experienced in both network and audio programming, I believe. The compression and encryption code should be usable with little or no modification. The bulk of the work would be in the user interface, network driver, and audio input/output which, due to great differences between Windows and the Macintosh, would have to be essentially rewritten. If you're interested in making a Mac version of Speak Freely, please let me know.

I don't get it. I've installed Speak Freely and it runs OK, but nothing happens when I connect to the IRC server. What gives?
Speak Freely is a telephone, not a party-line chat program like IRC. You run a copy on your machine, the other person runs a copy on theirs, and then you talk to one another person-to-person--there's no server in the loop nor any need for one. Somebody could certainly make a voice chat program, but this isn't it. If your network supports multicasting, you can use that facility to organise conference groups individuals can join and leave at will.

Can Speak Freely talk to other network voice program?
Yes, as long as the program supports either Internet Real-Time Protocol (RTP) or the protocol used by the Lawrence Berkeley Laboratory's Visual Audio Tool (VAT). Speak Freely automatically detects which protocol a program is sending and displays the protocol in the connection window. When transmitting to a user running an RTP or VAT compatible program, be sure to set Options/Protocol to the protocol that program requires. Many commercial Internet voice programs use proprietary protocols to guarantee users can only talk to others with the same program. Until the vendors of these products adopt RTP as a means of communicating with other voice applications, it will not be possible to communicate with users of such products.

How can I make sure Speak Freely is always running on my machine?
Put a copy of the Speak Freely icon in your StartUp program group (or whatever it's called if you're running a non-English edition of Windows). You'll probably want to check the "Run Minimized" box so it starts as an icon. If you check the Look Who's Talking menu item, the Speak Freely window will automatically pop open whenever a remote machine makes a connection to yours. If you'd like to automatically establish one or more ready-to-use connections, specify the names of the connection files describing them on the command line, separated by spaces.

Help! I'm trapped behind a firewall and can't talk to people at other Internet sites. What can I do?
Little or nothing, unfortunately. Speak Freely communicates using Internet UDP protocol on non-privileged port 2074. Most firewalls block all non-privileged (and hence unknown) port number packets, since there's no way to know they aren't being used by a mole or a Trojan Horse application to transmit sensitive data to a remote site. Speak Freely uses a nonprivileged port precisely to avoid the need for involving your system administrator in installing the program, but if you're behind a firewall you have no alternative. If you can persuade your jovial sysadmin to allow UDP packets on port 2074 to pass both directions through the firewall, you'll be all set, but the odds of this are extremely slim--I certainly wouldn't permit it were I your site manager. Once there's a known port out of your system, any program, not just Speak Freely, can transmit anything it likes accessible on your system to any other host on the Internet; if you permit that, why have a firewall in the first place? Basically, you'll just have to wait until the demand for network voice conferencing becomes strong enough at your site that your administrator installs a secure proxy tool to create a bridge across the firewall that Speak Freely can cross. By the time that happens, Speak Freely will support the proposed Internet Real-Time Protocol (RTP), so a proxy server for that protocol will allow Speak Freely, along with other RTP conferencing tools, to communicate across the firewall. In the short term, there's nothing you or I can do to get across the firewall. In the short term, there's nothing you or I can do to get across the firewall. If you do decide to create a bridge across your firewall for network voice, you should probably also allow packets on ports 5004 and 5005 to pass--this is the standard port pair for RTP protocolProtocol.

Aren't you going to wreck the Internet by clogging it with all this sound traffic?
This is a legitimate concern in regard to video conferencing programs, but not with a voice-only tool like Speak Freely. With GSM compression, real-time audio requires a bandwidth of just 1650 bytes per second. This is far less than a typical FTP session, and people regularly make multi-megabyte FTP archives available without fear of clogging the Internet. A user accessing one of the many graphics-rich World-Wide Web sites can easily consume more Internet bandwidth than Speak Freely. In addition, the load created by real-time audio is inherently self-limiting. As a network link approaches saturation, the consistency of packet delivery time becomes dramatically worse, while non-real-time applications such as FTP and Web transfers simply begin to smoothly slow down. Long before the links between two sites reach their bandwidth limit, the audio users will have given up in frustration with break-ups and lost sound, to try again, perhaps, when the network is less busy.

Why do face images go all weird when more than one person is connected at once?
This occurs when your system has a 256 colour display board, and each face has its own set of 256 colours. The active connection will be displayed with the correct colours but other connections must use a default colour table. If you upgrade your display adaptor to full-colour, multiple face images will display correctly.

How secure is the encryption?
I've used the best algorithms I know of and applied them in the best ways I could given the constraints of real-time audio, fallible communication networks, and the computing power of contemporary personal computers. But I'm not a professional cryptographer or cryptanalyst and even if I were, you shouldn't believe something is secure just because the author claims it to be. One of the reasons I'm releasing complete source code for Speak Freely is to permit independent evaluation of the implementation and application of encryption within the program by experts in the community. With time, a consensus will emerge as to the degree of security Speak Freely provides and how to remedy any perceived weaknesses in future releases. Key file encryption is very insecure, but I already warned you about that; it's intended purely as a last-ditch alternative for users with computers too slow to run any of the other forms of encryption, yet who prefer any protection, however weak, to transmitting entirely in the clear.

Why do you use datagram protocol with no end-to-end acknowledgment that would permit detecting and correcting errors?
Network transmission delays rule out end-to-end acknowledgment. Audio has to be delivered in real time to be intelligible. Waiting for an ack from the other end would, in many cases, require delaying up to a second before sending the next packet. The best we can do is blindly spray packets at the other end in the hope enough will arrive with sufficiently consistent delivery time to be intelligible. Over slow links to distant sites, several packets will be flowing through the network toward the destination at a given time. Providing connections with guaranteed bandwidth and consistent delivery time is one of the main challenges in extending the Internet to accommodate real time audio and video communication.

I run the Windows debug kernel and I get whatever messages when I do...
I've sweated blood to try to make this thing debug kernel clean, and as of this writing with half-duplex audio hardware, attempting to open input while output is open causes several "GlobalReAlloc failed" and "LocalAlloc failed" messages from the Kernel, which it presumably handles correctly since no apparent harm is done. But, as a battle-weary Windows warrior, I have no illusions that I've "found the last one". If you see warnings or errors unrelated to half-duplex output to input transitions, please let me know and provide as much information as you can about precisely what you were doing, what message(s) you got, whether you could reproduce the problem, and which sound card, network interface, and network (Winsock) software you're using. Thanks in advance.

Next Previous Contents