APRO Hardware Support

Async Professional (APRO) is a serial communications library that often needs to interface with hardware.  Usually, the hardware is a modem or other telephony device, and we frequently get asked which modems or telephony devices work with APRO.  This document will attempt to answer that question with friendly advice and anecdotal information.

As a matter of policy, TurboPower does not recommend any particular hardware for use with APRO.  There are several reasons for this; the biggest reason is that we shouldn't recommend what we can't control. If APRO was an end-user application, we could recommend some specific hardware because we would know exactly what we would do with the hardware, and what conditions we would do it under.  Since APRO is a library being used in someone else's application, we don't know how it will be used. 

For the purposes of this document, we'll consider the hardware in four categories that are likely to be used by APRO: data transfer, automated voice, fax, and IP Telephony/Voice Over IP.  We'll focus on the requirements imposed by the category.

Data Transfer hardware

Data transfer is the core of APRO, whether it is just sending and receiving characters through the serial port or full-blown file transfer protocols.  For the vast majority of cases, the data transfer will occur directly through the serial port (via a direct connection to another device) or through a modem. 

Cable connections

A direct connection is made when one serial port is connected to another serial port through some kind of cable.  This could be a null-modem cable so two PCs can communicate to each other, a regular serial cable to connect to a modem, or it could be a cable specialized for a particular device.  The cable is only a transport mechanism, and it needs to have all of the correct wires connected to the correct pins, and be in serviceable condition. One customer recently reported that he couldn't get the RI (Ring Indicator) status trigger to fire, after a bit of research we found out that most of the serial cables available today don't even have the RI pin connected (the use of RI has dropped dramatically over the years, the cable manufacturers can save a bit of money by not wiring that pin).  Old cables can have corrosion that can degrade or block the signal enough to interfere with normal communications also.

Modem connections

For remote direct connections, where one device talks to another device remotely located, the hardware of choice is almost unanimously the modem.  A modem converts the digital signals from the device into analog signals that can be transmitted over phone lines (it actually MOdulates and DEModulates the signals, which is why the devices are called modems).  Almost any modem will connect to almost any other modem.  There are some modems out there that will not be able to negotiate with other modems, and if the modems can't connect, neither can we.  Those are in the minority; we very seldom get a report of this kind of problem.  Most of the time, one modem or the other is configured to require a particular connection type (such as V.90, V.32, etc); if the other side doesn't support that type of connection the connection attempt would fail. This is one of the benefits of TAPI; the connection requirements can be tweaked through the modem's property page instead of mucking about with modem commands.


Since we've mentioned TAPI; that opens up a whole new arena in hardware compatibility. TAPI (the Telephony API) is a Microsoft/Intel initiative created to provide a standardized interface to a variety of modems.  The TApdTapiDevice, TApdSapiPhone and TApdVoIP components all use TAPI.  There are several different versions of TAPI that are either installed with Windows or available as an update from MS.  APRO negotiates for TAPI 1.4, which is the version that shipped with the original Windows 95.  All subsequent versions of TAPI are supposed to be backwards compatible to 1.4, and MS has expressed an interest in maintaining that compatibility in future versions of TAPI.  TAPI uses modem drivers to provide a standard interface to different modems.  The modem drivers are really INF files that define the modem's commands and responses for configuration, connections, errors, etc.  Modems drivers are frequently updated to provide fixes or enhancements so check the modem manufacturer's web site often for updated drivers.  If the modem driver is faulty, then the modem could be configured incorrectly, which can lead to problems with the data transfer. 


Multi-port/Multi-modem boards

PCs usually come with one or two built-in serial ports, which is enough for the casual user — but not for an APRO developer.  Several companies offer multi-port and multi-modem boards that can give you more ports than you'll ever need.  You'll want an "intelligent" board, one that has built-in functionality to process the data before it gets to your application (see the section on Software modems later in this document).  Here at TurboPower we use several different brands of multi-port boards ; we have internal boards that provide 2, 4, 8 and 16 extra ports from Comtrol, Digi,  Sealevel and a few others.  All of the ports are accessible just like a regular, on-board serial port.

Line parameters

Data connections can be established with different line parameters.  The most common is 8 data bits, no parity bit, and 1 stop bit (8N1); but some systems require variations of those parameters (such an 7E2).  Not all devices support all parameters.  There are several brands of modems that only support 8N1 (they are designed solely for Internet connectivity), and attempts to use other parameters will fail.  Some modems will fail silently; they'll let you change the port parameters, but won't actually change anything or provide an indication that they failed.  Most of those modems are software modems....

Software modems

A software modem is a modem that uses the CPU of the host system (the system that the modem is plugged in to) to process the data.  It is a cost-cutting measure by the modem manufacturers; they don't need to add a Digital Signal Processor chip, they implement that functionality through extra software drivers. Since things like error correction and data compression are pushed onto the host CPU, they are much more susceptible to data corruption.  One customer reported consistent data loss when using APRO.  It turned out that the host system did not meet the minimum system requirements of the modem, and the data loss occurred when other applications were started (loading the application took all of the CPU time from the modem drivers).

Modem requirements

APRO doesn't require much from a modem; it's just a piece of hardware used to create a  connection.  If you are using TAPI, then you'll want a modem that is on the MS Hardware Compatibility List (http://www.microsoft.com/hcl/).  That simply means that MS has verified that the modem is capable of running under Windows (you'd be surprised at the number of big-name modems that aren't on the list because they can't pass the MS tests). 

Make sure the modem is capable of the line parameters (data bits, stop bits, parity) that your connection will require.

Automated Voice Hardware

One of the benefits of using TAPI is that it supports automated voice.  Automated voice applications can interact with human callers by detecting their key presses and playing/recording wave files.  An automated voice application will generally do something like answer a call, play a pre-recorded greeting message, detect DTMF tones, etc.  APRO supports automated voice only through TAPI.

Operating system support

TAPI provides automated voice support through Unimodem/V and Unimodem/5.  Unimodem/V is the TAPI Service Provider (TSP) for Windows 95 OSR2, 98 and ME; Unimodem/5 is the TSP for Windows 2000 and XP.  The initial release of Windows 95 does not have Unimodem/V, but it is available from Microsoft as an update (they keep changing the locations where it can be downloaded from, so do a search of www.microsoft.com if you need it).  Windows NT4 uses Unimodem (notice the lack of /V and /5), and does not support automated voice using the standard TSP.  (See the section on dedicated voice boards later for more info about NT4.)

Dialing, TAPI and automated voice

Unimodem/5 and Unimodem/V were built to provide limited voice support for answered calls.  Answered calls have definite connection states that can be monitored accurately.  The answering side knows exactly when the call is connected (after all, it knows when it answered the call). Unimodem/x was designed for answered calls, dialed calls just 'happened to work'.  When TAPI dials a number in voice mode, it generates a connection message immediately after dialing; regardless of whether the remote side answered or not.  This is because Unimodem/x was designed for answered calls, and designed for the low- to mid-range voice modems (the ones that the majority of Windows users will have).  A modem can easily detect when a data connection is made, it's after both sides negotiate a mutually supported connection parameter set.  Detecting a voice connection is a different animal entirely.  Regular voice modems just aren't capable of detecting when voice energy enters the line, they can't tell the difference between the ring back and someone saying "hello".  As a result of this, Unimodem/x doesn't even look for call progress notification from the modem.  The section on dedicated voice boards discusses this further.


Automated voice applications can use either voice modems or dedicated voice boards.

Voice modems

A voice modem is simply a modem that supports automated voice.  When a voice modem is installed, TAPI loads the modem's drivers, and then loads the modem's wave drivers.  The modem drivers tell TAPI how to configure the modem for voice, and the wave driver converts audio data into something that the modem understands.  TAPI again provides a standard interface to the audio encoding/decoding; something that is needed because modems differ greatly in their audio capabilities and supported formats.

The quality of the wave playback and recording is directly related to the capabilities of the modem and wave drivers.  Most of the off-the-shelf voice modems (the ones you can find in your local computer store) are designed for simple answering-machine type applications, so their wave quality will generally be barely acceptable.  Some older USR modems will record, but the quality is so bad that it is almost unintelligible.  APRO can't do anything about that; it's a modem hardware problem.  Some modems are also better than others at detecting DTMF tones.  Again, it's a modem hardware problem.  The modem just isn't capable of reliable voice service.

 Most voice modems are built primarily for data communications and have voice functionality tacked on, almost as an afterthought. If you want reliable, high-quality automated voice, use a reliable, high-quality voice board....


Dedicated voice boards

If your project requires outbound call progress notification (so you can tell when a dialed call is answered), or higher quality audio playback/recording, then you'll want a dedicated voice board.  These are generally quite a bit more expensive than off-the-shelf voice modems, but are worth it for most automated voice applications. Their wave drivers usually convert more wave formats, and provide better audio quality; their DTMF detection is usually much more accurate; and they provide more accurate call progress notification.  Their greater functionality is usually through replacement TSPs that are designed to interface with the board's capabilities.  When you dial, you'll get the OnTapiConnect event when the remote side actually answers; some of them can distinguish between an answering machine and a person also.

One of the hidden benefits of their replacement TSPs is that they can usually be installed under Windows NT4, so your application can run on all of the 32-bit Windows platforms.  This used to be a huge reason to get a dedicated voice board (your alternative was to run only under Win9x), but now that Windows 2000 and XP have voice-capable TSPs it's not as big a deal as it used to be. 

The big thing to look for in a dedicated voice board is that it supports TAPI and the TAPI voice extensions (sometimes labeled "TAPI/WAVE" or "TAPI automated voice support").  Some dedicated voice boards use a board-specific API, and they are not accessible via TAPI.  If the board doesn't support TAPI, then APRO can't support the board.

Fax hardware

A large chunk of APRO deals with faxing, but only a few components relate to hardware. The TApdSendFax, TApdReceiveFax, and the TApdFaxServer component access the fax modem through the serial port to send and receive faxes.  Fax modems come in a few different flavors, defined by the fax class that they support.

Fax class 1 and 1.0

This fax class defines a fax protocol where the modem is merely a transport device, most of the fax handling is done by the software.  Fax class 1 is the original standard, Fax class 1.0 is basically a renamed class 1 to keep the official standard names standardized. Most modems will support class 1, and since the protocol is managed by the software the results are generally more consistent and controllable.

Fax class 2 and 2.0

Modem manufacturers and fax users soon realized that fax class 1 did a lot of things through software that could be done in the modem itself, so they started developing the next fax standard.  There were essentially two competing standards, one pushed by USR and the other by the rest of the modem world.  USR started releasing modems supporting their standard, and the international fax standards group endorsed the other.  Class 2 is the standard from USR, which is also used by several other manufacturers; class 2.0 is the “official” standard used by everyone else.  Performance-wise, class 2 and 2.0 are nearly the same.  The software tells the local modem what kind of connection it wants, the local modem negotiates with the remote fax device and tells the software what kind of connection to use.

Proprietary fax API

Some fax devices do not support the above fax classes, instead they use a proprietary fax API.  Brooktrout, Digi, Dialogic, and other high-end fax board manufacturers all have devices that fall into this category.  APRO does not support these proprietary APIs.  Some of the devices support one of the supported fax classes, we can use those through the fax classes.

 We haven't seen an off-the-shelf fax modem that APRO couldn't use, but some modems do perform better than others.  Get a modem that supports class 1/1.0 and 2/2.0.  That will give you something to fall back on if things go wrong.  If you're starting with class 2/2.0, you can drop down to class 1.


Faxing and software modems

While fax class 2/2.0 is implemented in the hardware to reduce the load on the software/CPU, some of the software modems implement faxing through their software drivers.  For modems like these, use TAPI to open the port.  When TAPI opens the port it will load and initialize the software drivers.

IP Telephony/Voice Over IP

IP Telephony/Voice over IP is a technology where audio and video can be transmitted through the network.  The connection-related hardware is the network card, and practically anything that gets you a TCP/IP connection will work just fine.  Microphones and video cameras, on the other hand, have a great deal to do with the quality of the audio/video streams.

Audio devices

For transmitting audio through IP Telephony, you'll want a good quality headset.  Something that places the microphone close to the audio source (usually your mouth) will give you a clearer audio stream than a hand held microphone sitting on your desk. 

Video devices

Likewise, you'll want a good quality video source to transmit video.  Image size, resolution, color mapping, contrast, frame rate, etc all come into play, as well as the speed of your connection.  When sending video on a 100MPS LAN, you can easily transmit and receive 640x480 live video; however, if you're on a 33.6K dial-up, you'll want something more like 160x120 or less.  The resolution, frame rate and color depth can usually be configured in the device property pages to tailor the size of the stream to the connection speed.

What we use

Here at TurboPower, the APRO engineers use a variety of hardware to support the library.  This variety is not all-inclusive, but they all work well in the environments and uses that we have for them.

Operating systems

Our primary development systems are Windows 2000 and XP, but we have multi-boot capabilities on most of our boxes to test under Windows 95OSR2, 98SE and NT4; as well as several different distributions of Linux.  All of us also have separate test boxes, usually running Windows 98.


We have boxes and boxes of modems, but all of us have found a few favorites that we use in everyday testing.  While compiling the initial list, I realized that most of these modems are no longer available, either because they have been replaced with more modern modems or because the company that made them is out of business.  Instead of listing everything that we're using, here are a few of the better modems in our stable:

Data/Fax Modems:

We haven't found a modem yet that we couldn't use for faxing, or that provided substandard data connections.  We've determined that we would much rather have external RS232 modems than internal or USB modems.  The externals can be replaced much easier than internals, and most of them have the all-important blinky lights on the front so you can see what the modem is doing.  The USB modems are generally OK, but their performance is very dependent upon the quality of the USB drivers.  One USR USB modem that we have is actually a software modem when connected via USB, but is a hardware modem when connected with the RS232 cable.  The USB drivers that came in the box were pretty bad, we had to reinstall Windows a few times until things happened to work.

Voice modems

For our regular day-to-day testing, we use a Supra Sonic 336V+ and a USR USB Voice FaxModem Pro (connected via RS232).  The Supra is an all-around good modem, although it has some problems detecting DTMF when received from a cell phone.  Wave quality is acceptable, both for playing and recording.  The USR has acceptable wave playback/record abilities, but the volume is pretty low.  We've had some reports from other customers using the same model USR, and they have said the volume is OK but there is a lot of static.

We also have a Dialogic Proline/2V voice board, but haven't used it lately.  The Dialogic boards are very good once you get them installed, their installation leaves a lot to be desired.


Choosing the right hardware is a big part of making your project successful.  We've discussed the four major hardware classifications used by APRO, and provided tips to select the right one for the job.  There are several sites that provide reviews of hardware that may be of help in making the decision, http://home.attbi.com/~bpennypacker/tapifaq/tsplist.html is one of the better ones.  http://www.aprozilla.com/ModemReviews/mdmdtoc.htm is also available for APRO developers to submit and read reviews of different hardware.


This site is not affiliated, endorsed, or otherwise associated with the entity formerly known as TurboPower Software. The owners and maintainers of Aprozilla.com were merely meager employees of the aforementioned organization, providing this site out of the pure goodness of their collective hearts. SourceForge.net Logo

Last updated: July 22, 2003.