[TriLUG] RE: Phone to use with PC

[Aaron S. Joyner]

sjackson at radarfind.com wrote:

>Scott
>
>OK.  As you mention: "I already have software that does what I want in the
>MS-Windows world" -- you already have this working.  My bad.
>
>It's clear I am not "getting" what you have running now in your non-Linux
>OS.  I was having a hard time imagining where you plugged your mic in and
>where you plugged your speakers in if not to you sound card, and how you get
>them to run full-duplex without feedback, while processing the audio across
>the PC to transfer to the modem card and then out to the phone trunk line in
>some way.  I don't have an M$ application that does this, myself.
>  
>
Perhaps I can try again to help clear up the confusion.  Apparently what 
Scott has is what's commonly referred to as a "Voice modem".  In the AT 
command set, there is an extra mode, in addition to the traditional data 
and fax modes.  It's usually accessed by sending a command something 
along the lines of AT+FCLASS=X where X is 0, 2, 2.0, or 8 corresponding 
to data, fax class 2, fax class 2.0, or voice.  Some modems will also 
support other modes, such as a proprietary fax mode, or class 3 fax, or 
some other standards.  And since these commands are *not* part of the 
original Hayes Acura defacto standard, they tend to vary from one modem 
to another in subtle ways, and sometimes they are all-together different.

What this mode causes the modem to do, is do the DSP work Steve was 
describing on the card, and hand you an audio stream in a variety of 
formats.  Modems doing this task are typically half duplex, although 
some manage to do full duplex.  Not only does the hardware have to 
support full duplex (and for the reasons Steve detailed they usually 
don't), but the software coding required to make full duplex work is 
apparently a good bit trickier.  It seems the modems responses to AT or 
voice-mode commands while delivering an audio stream in voice mode tend 
to be finicky and delayed.  Couple that with the fact that most hardware 
doesn't support it, and thusly most software in Linux doesn't bother.  
The typical way to interact with the other end is via setting a timeout 
for a response.  Essentially, you tell the modem, "deliver this audio 
stream and wait until you detect a DTMF tone, or X seconds have 
passed."  Some modems can successfully detect DTMF while they're 
delivering the audio, some can't - it varies from hardware to hardware 
(again, see full duplex discussion above).

I mentioned at the head of the last paragraph that the modem can be 
sending you audio in a variety of proprietary and pretty raw formats.  
Essentially, this is 8bit pcm data, clocked at a certain frequency.  In 
some hardware, you can set the frequency, or perhaps even choose from 
one of a few voice data formats, but these are unusual luxuries.  
Typically, software (such as the a-fore-mentioned vgetty) that 
interfaces with these cards has to code numerous different codecs to 
deal with the different types of modems.  Fortunately, there are only a 
finite number of actual chipsets out there, in practice only about maybe 
8 or so different types of data input are common, most are variations on 
one of those basic types (although there can easily be up to 50 to 100 
various combinations of base type, and extraneous options for that type).

Hopefully this has been a short and comprehensive tour into what your 
voice modem can and can't do, and why it's not going to be terribly well 
supported in Linux.  Yes, it is possible to do what you want.  Yes, the 
features to allow it to be a full duplex speakerphone are mostly in the 
hardware.  You (Scott) already knew these things, from having used the 
software that came with your modem in Windows.  Unfortunately, the scope 
of modems is wide, and there's (thus far) hasn't been a whole lot of 
interest for this type of feature in the Linux world, in my humble 
experience.

As I said in my previous email, I'd look into derivatives of the vgetty 
project, perhaps something will meet your needs, but I have never run 
across such a beast.

Aaron S. Joyner