problems with soundmodem (userspace)

problems with soundmodem (userspace)

[Jochen Schaeuble]

Hi,
I have several problems setting up the userspace version of soundmodem 
with 9k6. Everything works perfect if I only send a small set of 
characters (like c or m) - but sometimes a bit slow. If I enter a larger 
amount of text (like a message) the connection is lost after about 10 
minutes of retries. Any hints what I'm doing wrong? I use a Yaesu FT-817 
with Debian testing (Kernel 2.4.22, ALSA). The parameters of soundmodem 
are as follows:

txdelay="150" slottime="30" ppersist="30" fulldup="0" txtail="25"

As terminal I use xcall.

Is it better to use the kernelspace driver?

vy 73 de Jochen DG1PSI

Re: problems with soundmodem (userspace)

[Dave Platt]

Jochen Schaeuble <psionic@psionic.de> wrote:
> Hi,
> I have several problems setting up the userspace version of soundmodem 
> with 9k6. Everything works perfect if I only send a small set of 
> characters (like c or m) - but sometimes a bit slow. If I enter a larger 
> amount of text (like a message) the connection is lost after about 10 
> minutes of retries. Any hints what I'm doing wrong? I use a Yaesu FT-817 
> with Debian testing (Kernel 2.4.22, ALSA). The parameters of soundmodem 
> are as follows:
> 
> txdelay="150" slottime="30" ppersist="30" fulldup="0" txtail="25"
> 
> As terminal I use xcall.
> 
> Is it better to use the kernelspace driver?

From what I've seen, problems with the user-mode soundmodem driver
can fall into the following categories:

-  Incorrect audio levels.  A receiver whose audio output is too
   "hot" can overdrive a PC's sound card input, clipping the
   waveforms and distorting the signal.  Similarly, a PC whose
   audio output level is set too high can overdrive the rig's
   microphone or accessory audio input, clipping the signal or
   overdeviating.

   The 9k6 FSK modulation is, I understand, quite "touchy" in
   terms of the transmit audio level.  Since you're driving the
   modulator directly, too high an audio output level can
   easily over-deviate your signal, and you might drive the
   signal out past the receiving radio's discriminator lock
   range.

   See if you can find someone in your area who has a
   deviation/modulation meter, and see whether you're pushing the
   transmit deviation too hard.

-  Incorrect setting of the radio.  For 9k6 FSK, you can't use
   the mic and speaker jacks.  You must use an audio interface
   which bypasses the transmit equalization circuitry, and which
   gives you access to the receiver's discriminator output without
   re-equalization.  Some radios with auxiliary audio jacks have
   a menu setting e.g. "1200" or "9600" - if the FT-817 has such
   a menu, make sure you've selected 9600.

-  Sound-card resampling problems.  Many modern PCs use sound
   interfaces based on the AC97 codecs, which have only a couple
   of hardware sampling rates.  The soundmodem driver may be expecting
   to use a different sampling rate.  If the soundmodem sample rate
   and the codec sample rates don't overlap, then somebody has to
   re-sample the audio data - some chipsets do this in hardware, while
   others have no such ability and require the CPU and drivers to do
   the resampling.  ALSA's OSS-compatibility driver will try to do
   resampling, but some reports on this group seem to indicate that the
   resampling code has bugs in it and can result in bad samples being
   transmitted or received.

Also, packet transmissions in general and (I think) 9k6 in particular
are often quite sensitive to RF signal quality.  In particular,
multipath reflections can result in enough inter-symbol interference
to render the signal unreadable.  Use of directional beam antennas,
mounted high up in the clear, may clean up the signal enough to make
the channel usable.

Another thing to check is to make sure that your radio isn't set
in a power-saving mode, which leaves the receiver turned off much
of the time.  These modes play merry hell with packet, as the SYNC
bursts are often lost.

My guess is that the kernel soundmodem driver is probably not going
to be the cure for your problem... the fault lies elsewhere.

Re: problems with soundmodem (userspace)

[Thomas Sailer]

Dave Platt wrote:

> -  Sound-card resampling problems.  Many modern PCs use sound

This is in fact a big problem. While soundmodem does have the resampling
code and is able to use any sampling rate above a certain minimum required
for the mode, some driver emulation layers interfere with this. ALSAs OSS
emulation layer is a culprit here, it's also quite buggy.

I've put a soundmodem version with a rather experimental native Alsa API
on http://www.baycom.org/~tom/ham/soundmodem/soundmodem-0.9.tar.gz

Tom

Re: problems with soundmodem (userspace)

[Andrea Borgia]

[-- Attachment #1: Type: text/plain, Size: 1778 bytes --]

Thomas Sailer wrote:

> I've put a soundmodem version with a rather experimental native Alsa API
> on http://www.baycom.org/~tom/ham/soundmodem/soundmodem-0.9.tar.gz

I am having the same problem with rx packets being lost so I gave this 
version a try. Now RX is apparently fine, but on the first TX packet the 
soundmodem crashes with the following output:

-cut-cut-
ALSA lib pcm_hw.c:494:(snd_pcm_hw_start) SNDRV_PCM_IOCTL_START failed: 
Broken pipe
sm[21164]: snd_pcm_start: Broken pipeALSA lib 
pcm_hw.c:494:(snd_pcm_hw_start) SNDRV_PCM_IOCTL_START failed: File 
descriptor in bad state
sm[21164]: snd_pcm_start: File descriptor in bad statesm[21164]: audio: 
snd_pcm_readi: Broken pipec
-cut-cut-

I tried using something else than hw:0,0 but it either results in a 
config error or in a similar crash. Here is the relevant info about my 
Alsa setup, is there any obvious mistake in the config?

/proc/asound/cards:
0 [V8235          ]: VIA8233 - VIA 8235
                      VIA 8235 at 0x1400, irq 9

/proc/asound/devices:
   0: [0- 0]: ctl
  17: [0- 1]: digital audio playback
  25: [0- 1]: digital audio capture
  16: [0- 0]: digital audio playback
  24: [0- 0]: digital audio capture
  33:       : timer

/proc/asound/pcm:
0-00: VIA 8235 : VIA 8235 : playback 4 : capture 1
00-01: VIA 8235 : VIA 8235 : playback 1 : capture 1

/proc/asound/version:
Advanced Linux Sound Architecture Driver Version 1.0.4rc2 (Tue Mar 30 
08:19:30 2004 UTC).
Compiled on Jun 12 2004 for kernel 2.6.6clarisse.


B73,
Andrea.

-- 
Homepage: http://andrea.borgia.bo.it     /    Amateur radio: IZ4FHT
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[-- Attachment #2: soundmodem.conf --]
[-- Type: text/xml, Size: 589 bytes --]

<?xml version="1.0"?>
<modem>
  <configuration name="Packet">
    <channel name="Channel 0">
      <mod mode="afsk" bps="1200" f0="1200" f1="2200" diffenc="1"/>
      <demod mode="afsk" bps="1200" f0="1200" f1="2200" diffdec="1"/>
      <pkt mode="MKISS" ifname="sm0" hwaddr="IZ4FHT-1" ip="192.168.10.2" netmask="255.255.255.0" broadcast="192.168.10.255"/>
    </channel>
    <chaccess txdelay="500" slottime="100" ppersist="40" fulldup="0" txtail="10"/>
    <audio type="alsa" device="hw:0,1" halfdup="1" capturechannelmode="Left"/>
    <ptt file="/dev/ptt"/>
  </configuration>
</modem>

Re: problems with soundmodem (userspace)

[Jochen Schaeuble]

Hi,
thanks for your reply. I've found the problem. As you suggested it had 
something to do with the audio level. The soundcard-interface I use here 
seems to have some problems. If I directly connect the audio output of 
the soundcard to the data input of the TX everything works.

Thanks for your help.

vy 73 de Jochen DG1PSI

Dave Platt wrote:
> Jochen Schaeuble <psionic@psionic.de> wrote:
> 
>>Hi,
>>I have several problems setting up the userspace version of soundmodem 
>>with 9k6. Everything works perfect if I only send a small set of 
>>characters (like c or m) - but sometimes a bit slow. If I enter a larger 
>>amount of text (like a message) the connection is lost after about 10 
>>minutes of retries. Any hints what I'm doing wrong? I use a Yaesu FT-817 
>>with Debian testing (Kernel 2.4.22, ALSA). The parameters of soundmodem 
>>are as follows:
>>
>>txdelay="150" slottime="30" ppersist="30" fulldup="0" txtail="25"
>>
>>As terminal I use xcall.
>>
>>Is it better to use the kernelspace driver?
> 
> 
> From what I've seen, problems with the user-mode soundmodem driver
> can fall into the following categories:
> 
> -  Incorrect audio levels.  A receiver whose audio output is too
>    "hot" can overdrive a PC's sound card input, clipping the
>    waveforms and distorting the signal.  Similarly, a PC whose
>    audio output level is set too high can overdrive the rig's
>    microphone or accessory audio input, clipping the signal or
>    overdeviating.
> 
>    The 9k6 FSK modulation is, I understand, quite "touchy" in
>    terms of the transmit audio level.  Since you're driving the
>    modulator directly, too high an audio output level can
>    easily over-deviate your signal, and you might drive the
>    signal out past the receiving radio's discriminator lock
>    range.
> 
>    See if you can find someone in your area who has a
>    deviation/modulation meter, and see whether you're pushing the
>    transmit deviation too hard.
> 
> -  Incorrect setting of the radio.  For 9k6 FSK, you can't use
>    the mic and speaker jacks.  You must use an audio interface
>    which bypasses the transmit equalization circuitry, and which
>    gives you access to the receiver's discriminator output without
>    re-equalization.  Some radios with auxiliary audio jacks have
>    a menu setting e.g. "1200" or "9600" - if the FT-817 has such
>    a menu, make sure you've selected 9600.
> 
> -  Sound-card resampling problems.  Many modern PCs use sound
>    interfaces based on the AC97 codecs, which have only a couple
>    of hardware sampling rates.  The soundmodem driver may be expecting
>    to use a different sampling rate.  If the soundmodem sample rate
>    and the codec sample rates don't overlap, then somebody has to
>    re-sample the audio data - some chipsets do this in hardware, while
>    others have no such ability and require the CPU and drivers to do
>    the resampling.  ALSA's OSS-compatibility driver will try to do
>    resampling, but some reports on this group seem to indicate that the
>    resampling code has bugs in it and can result in bad samples being
>    transmitted or received.
> 
> Also, packet transmissions in general and (I think) 9k6 in particular
> are often quite sensitive to RF signal quality.  In particular,
> multipath reflections can result in enough inter-symbol interference
> to render the signal unreadable.  Use of directional beam antennas,
> mounted high up in the clear, may clean up the signal enough to make
> the channel usable.
> 
> Another thing to check is to make sure that your radio isn't set
> in a power-saving mode, which leaves the receiver turned off much
> of the time.  These modes play merry hell with packet, as the SYNC
> bursts are often lost.
> 
> My guess is that the kernel soundmodem driver is probably not going
> to be the cure for your problem... the fault lies elsewhere.