Author: Ivan Schréter
The new release 0.2.x contains a number of big changes in the code. It is not yet completely "clean", in the sense there might be some problems.
Currently known open points waiting for resolution:
Additionally, it's well possible there are some other bugs as well. It was tested on Kubuntu 7.10 with Linux kernel 2.6.22-14-generic on an AMD 64-bit machine. ISDN hardware was Fritz!Card PCI (an old one from year 2000), with fcpci driver (included in ubuntu). It also worked with mISDN driver, but this driver causes the machine to hang on suspend-to-disk.
Older versions of ant-phone used OSS (open sound system) for audio I/O. This had the disadvantage that only one application could use the hardware.
With ALSA, most Linux distributions come with configured dmix plugin, which allows several programs to open the device in parallel. So if you are listening to your MP3-collection, you will still hear the phone ringing and can even talk in parallel.
Note: Using ALSA hardware devices directly (e.g., "hw:0") is discouraged. It is recommended to use dmix/dsnoop devices mapped via asoundrc. Most Linux distributions have already configured "default" device to use dmix and dsnoop ALSA plugins. If yours doesn't or if you have special configuration (e.g., second sound card for the phone), please consider setting it up (see for instance http://wiki.ubuntuusers.de/.asoundrc for more information).
With new CAPI 2.0 support, it is now possible to run several CAPI 2.0 programs on the same machine without interfering with each other. Furthermore, as it's a standardized protocol, it brings also some other advantages. Some interesting examples:
To create an answering machine for your computer, simply install package capisuite, which is most probably available for your distribution, configure it and run it concurrently with ant-phone.
If you don't pick up the phone within configured interval, capisuite's answering machine will pick up the call, record it and mail it to you.
Of course, you can use any other CAPI 2.0 capable answering machine program as well.
This is untested, however: There is ISDN hardware, which can provide remote-CAPI capability. For instance, there are some HOWTOs in net, how to convert Fritz!Box router into a remote-CAPI capable one. Similarly, you could connect via TCP/IP to another computer with CAPI-capable ISDN card and rcapid.
In one word: latency.
Previous versions used events triggered from GTK GUI main loop, which were quite unreliable in their timing, given their nature as UI events.
Starting with version 0.2.0, ISDN connection and audio input use their own threads for optimum response times to outside events (ISDN data input or audio data input) and push the data to the other device. Main thread then works as a kind of coordinator, which handles call setup and teardown as well as UI.
Threading allows for much lower latency (<=150ms, can be made configurable later based on available CPU power) as well as much lower CPU consumption (normally not measurable during the call).
With new I/O handling, also recording has been improved. Recorder now uses two ring buffers for incoming and outgoing audio data. It tries to "stitch" audio block perfectly together, but if a slippage occurs (either way), it can handle it properly and either insert duplicate data or discard some samples. Ring buffers are flushed asynchronously in main thread. This results in clear recordings.
Migration from previous releases should go smoothly.
You should name your ALSA devices in settings (instead of "/dev/dsp" you'd use something like "default"). If you don't do it, the program will use "default", if it cannot open specified device name.
In older releases, window popup on incoming call was on by default. This has been changed now. So you will probably want to turn off popup.
Unfortunately, fcpci driver doesn't properly do suspend/wakeup for my ISDN card. The card is left in a funny state, which seems operational, but the ISDN bus is down. So it's not possible to make or accept calls. Removing and loading the fcpci kernel module fixes the problem.
I assume, there are also other cards with similar problems. Therefore, we now have two workaround options --sleep and --wakeup, which you can use in your suspend/resume scripts (in /etc/acpi/suspend.d/ and /etc/acpi/resume.d/) to close CAPI connection and restore it afterwards. You would call it like:
su -c "DISPLAY=:0 /usr/local/bin/ant-phone --sleep" <username> su -c "DISPLAY=:0 /usr/local/bin/ant-phone --wakeup" <username>
Furthermore, you should remove the offending module by adding it to MODULES in /etc/default/acpi-support, so it gets unloaded/reloaded on suspend/resume.