You must press the 'SPACE BAR' to start transmitting sound. You also won't hear anything until the other person starts sending sound successfully to you. You should have an icon of an 'ear', which indicates that you are sending sound out. The icon of a phone means that you are not sending out sound.

Test your microphone

In Microsoft: Programs -> Accessories -> Entertainment -> Sound Recorder

Test your microphone by recording something and playing it back. Usually the volume controls for recording or playing back sound from your microphone are not correctly set by default. Test this first.

(The following was contributed by John Deters). 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" application (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.

The Audio Monitor display may help in troubleshooting input and output audio settings.

Little or nothing, unfortunately. Speak Freely communicates using Internet UDP protocol on non-privileged ports 2074 through 2075 and TCP protocol on port 2076 (the latter only if you're using a Look Who's Listening server). 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 packets on ports 2074 through 2076 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. 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 protocol.

Find a free dynamic DNS service

Register and set your computer up for free dynamic dns entries at http://www.dyndns.org/services/dyndns/ or http://www.no-ip.com/ You can get a free DNS name like: bobf@homeip.net even though your IP address changes. Linux users can use a program called "ez-ipupdate". http://ez-ipupdate.com/ . Windows users can install a program called "DeeEnEs" at http://palacio-cristal.com/default.asp?main=/Products/DeeEnEs/. Other clients are listed at: http://www.dyndns.org/services/dyndns/clients.html

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.

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. The Phonebook/Search... menu item permits you to access a Look Who's Listening server to locate other people running Speak Freely.

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.

As soon as somebody makes one. I have neither 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 get in touch (via the Speak Freely mailing list) so you can see if anybody else is already working on such a project.

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.

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.

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.

For Microsoft:

Put a shortcut to Speak Freely in your Startup folder (or whatever it's called if you're running a non-English edition of Windows). You'll probably want to check the Options/Window Display Modes/Start Minimized menu item so Speak Freely starts as an icon. If you check the Use Notification ("System Tray") Icon and Hide When Minimized items as well, Speak Freely will lurk as a small icon to the right of the taskbar until you activate it by clicking the icon. If you also check the Open on New Connection item in this menu, the Speak Freely window will automatically pop open whenever a remote machine connects 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 of the shortcut, separated by spaces.

For Linux

There are a few ways to do this. I forget at the moment. :)

Voice compression using common GSM, CELP, or Speex codecs use less than 1-2 kB/sec. This is less than half of the bandwidth used by your normal dialup connection.

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.

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.

One of the reasons the complete source code for Speak Freely is available 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.

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'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 announce them to the Speak Freely mailing list 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.