user soundmodem problems on Inspiron 8200 i810 chipset...

user soundmodem problems on Inspiron 8200 i810 chipset...

[braddock]

Hi all,
I've been having problems getting user soundmodem to reliably copy on
an Inspiron 8200 linux RedHat9 machine with Intel i810 sound chipset
with a 2.4.25 kernel using the ALSA 1.03 drivers with a Kenwood TH-F6A
HT.  Any help is GREATLY appreciated.

Be warned that this is my first attempt at AX.25, but at this point
I'm pretty sure something must be amiss.

I'm attempting to receive frequent APRS traffic on 144.39 from an APRS
repeater located line-of-sight only about a mile away with 1200 baud
afsk mode with a very clean signal.  Demodulator parameters are afsk
mode, 1200 bits/s, "Frequency 0"=1200, "Frequency 1"=2200.

Using the soundmodemconfig diagnostic windows, what I see is what
appears to be a perfect clean signal during transmission, but an
uselessly high error rate in the decoding.  In the "Receive-Packets"
diagnostic window, when I turn the passall CRC check flag on, I'm
seeing messages that are 30% garbled at best (based on the callsign
addressing portions I can actually read).  With CRC checking enabled,
no packets are passed.

In the scope window I see glimpses of visually very clean modulated
sine waves with no clipping (I would dare say I could probably decode
the bitstream manually from just looking at the scope given enough
time).  The Spectrum Display shows well defined peeks at around 1200
and 2200 hz (twice the noise floor or better assuming the scale is
linear) with a band between during transmission.

Thinking it might just be very sensitive to signal levels, I've spent
literally hours adjusting audio levels of the radio and the mixer, and
swapped cables and adaptors.  I've attempted using line-in (both left
and right channels), mic-in, and even holding the radio speaker up to
the microphone (which doesn't seem to make things that much worse than
they are).

I've got my TH-F6A radio in it's dedicated TNC mode (though I've also
tried normal mode).

Does anyone have any ideas?  I've done a lot of googling and came
across one other posting to the list of a user with an i810 chipset
who had setup soundmodem successfully on two other systems but saw
similar noise problems on the third, but there was no public
resolution to the issue.

As a minor bug report FYI, soundmodem will not work with the OSS Intel
i810 drivers...it fails when it tries to put the driver into single
channel (non-stereo) capture mode.  THAT seems to be a driver issue
(which is why I'm now using ALSA).  That issue was reported to the
list before at http://he.fi/archive/linux-hams/200206/0002.html, but I
thought I might reiterate it.

Please CC: me with any response because I'm not on the list.

	-braddock

Re: user soundmodem problems on Inspiron 8200 i810 chipset...

[Patrick Ouellette]

Have you tried muting the microphone input?  I had problems a few years
back with reception, and it turned out that the mic input was active and
added just enough trash to mess up decoding.

Pat

Compile warnings on hfterm with Mandrake

[ravioli]

A lot of warnings in the last release of hfterm-0.5 can be removed by 
applying this diff.
More information on request.
Remi F4ECW

diff --recursive hf-0.5/dcf77/audioin.c hf-0.5.ORG/dcf77/audioin.c
38d37
< #include <stdlib.h>
diff --recursive hf-0.5/dcf77/audioout.c hf-0.5.ORG/dcf77/audioout.c
36d35
< #include <stdlib.h>
diff --recursive hf-0.5/dcf77/calccorr.c hf-0.5.ORG/dcf77/calccorr.c
33c33
< #include <stdlib.h>
---
 >
35d34
< #include <sys/time.h>
diff --recursive hf-0.5/dcf77/dcfdemod.c hf-0.5.ORG/dcf77/dcfdemod.c
33d32
< #include <stdlib.h>
diff --recursive hf-0.5/dcf77/dcfdemodpn.c hf-0.5.ORG/dcf77/dcfdemodpn.c
32d31
< #include <stdlib.h>
diff --recursive hf-0.5/dcf77/hbgdemod.c hf-0.5.ORG/dcf77/hbgdemod.c
32d31
< #include <stdlib.h>
diff --recursive hf-0.5/dcf77/xgintf.c hf-0.5.ORG/dcf77/xgintf.c
33d32
< #include <stdlib.h>
diff --recursive hf-0.5/hfterm/src/spectrum.c 
hf-0.5.ORG/hfterm/src/spectrum.c
31d30
< #include <string.h>
diff --recursive hf-0.5/l1/user/oss.c hf-0.5.ORG/l1/user/oss.c
38d37
< #include <stdlib.h>
172,175c171
<         struct timespec my_time_spec_nano ;
<         my_time_spec_nano.tv_sec  =   0 ; /* Seconds */
<         my_time_spec_nano.tv_nsec = 100 ; /* Nanoseconds */
<         nanosleep( &my_time_spec_nano /* 100 */ , NULL);
---
 >         nanosleep(100, NULL);
302c298
<     void * m = NULL;
---
 >     void * m;
525c521
<     void *m = NULL;
---
 >     void *m;
646c642
<                 if ( (!fragptr) && ( m!= NULL) ) free(m);
---
 >                 if (!fragptr) free(m);
diff --recursive hf-0.5/l1/user/refclock.c hf-0.5.ORG/l1/user/refclock.c
35c35
< #include <stdlib.h>
---
 >
diff --recursive hf-0.5/os/msg.c hf-0.5.ORG/os/msg.c
307c307
<     /* unsigned int err = ntohl(msg->hdr.err); */
---
 >     unsigned int err = ntohl(msg->hdr.err);
diff --recursive hf-0.5/proto/amtor.c hf-0.5.ORG/proto/amtor.c
31d30
< #include <stdlib.h>
diff --recursive hf-0.5/proto/mkgtortables.c hf-0.5.ORG/proto/mkgtortables.c
213,216c213
<     int i, j;
< #ifdef PARANOID
<     int k ;
< #endif
---
 >     int i, j, k;
diff --recursive hf-0.5/proto/pactor.c hf-0.5.ORG/proto/pactor.c
1020c1020
< #endif /* MARQ_BAD_CRC_GETOUT */
---
 > #endif MARQ_BAD_CRC_GETOUT
1764,1765d1763
< #if 0
<     /* Please see '#if 0' in this function... */
1767d1764
< #endif
diff --recursive hf-0.5/test/testcos.c hf-0.5.ORG/test/testcos.c
31d30
< #include <stdlib.h>
diff --recursive hf-0.5/test/testgettimeofday.c 
hf-0.5.ORG/test/testgettimeofday.c
8d7
< #include <stdlib.h>
diff --recursive hf-0.5/test/testoss.c hf-0.5.ORG/test/testoss.c
5d4
< #include <stdlib.h>
diff --recursive hf-0.5/test/testpoly.c hf-0.5.ORG/test/testpoly.c
5d4
< #include <stdlib.h>

Re: user soundmodem problems on Inspiron 8200 i810 chipset...

[braddock]

On Tue, Mar 09, 2004 at 02:50:38PM -0500, Patrick Ouellette wrote:
> Have you tried muting the microphone input?  I had problems a few years

I have tried muting it (as well as using the mic-in jack directly
instead of the line-in jack).

I did notice one anomaly that occurred frequently on the soundmodem
diagnostic scope that I'm thinking might be signs of trouble.  In the
capture, the line traced on the scope would occasionally draw a
straight horizontal line within the signal at random places (both
horizontally and vertically).  This "dead spot" seems to be uniformly
about 4 1200 Hz cycles (~3 ms).  This does not seem to be clipping
because it occurs at random levels.

Here is an excellent screen shot of the scope showing two instances of
this anomaly in an otherwise pretty clean looking signal:

http://braddock.com/soundmodem.png

I'm wondering if this is a sampling problem with the ALSA i810 driver?
If anyone could take a look at that scope image and let me know if
that's normal behavior within the scope or a sound capture problem it
would help us narrow this down.  It occurs at all sound levels AFAIK.

Also, I tried running soundmodem on a desktop system (vs my Inspiron
laptop) that also has the Intel i810 sound chipset and ALSA drivers,
with the exact same results.

All help much appreciated!

	-Braddock Gaskill

Re: user soundmodem problems on Inspiron 8200 i810 chipset...

[braddock]

I have found a (kludgy) fix to my i810 chipset sampling problems.

The problem does indeed seem to have something to do with the sound
sampling rate with the i810 ALSA driver.  By forcing soundmodem to
capture at the more standard 22500 samp/sec instead of the 9600
samp/sec that it wants to, I get PERFECT RECEPTION!  (now I wish I
hadn't ordered that hardware TNC this morning...*sigh*)

Specifically what I did was to force the sample rate in the
afsk/modem.c file in the modconfig() function.  soundmodem tries to
set it to 8*baudrate.  I just hard code it to 22500.

        /* *samplerate = 8 * s->bps;*/ /* OLD */
        *samplerate = 22500; /* NEW - braddock's ALSA kludge */

This presumably won't be sufficient for 9600 baud, but it
gets me working fine at 1200 which is all I need right now.

I suspect there is some portion of soundmodem which relies on that 8 *
bps sample rate.  One thing I did find is that if I force the rate to
48000 samp/sec, DCD stops working almost entirely.  Maybe Tom Sailer
could shed some light on this, or point me to code that I can fix it?
Or maybe it's just another driver quirk.  I also found that if I force
the rate to 8000 samp/sec that I saw the same anomaly in the scope
that I described for 9600 samp/sec.

It should be a simple matter to allow the user to add a prefered
sample rate on the command line.

	Braddock Gaskill

On Tue, Mar 09, 2004 at 03:35:42PM -0600, braddock@braddock.com wrote:
> On Tue, Mar 09, 2004 at 02:50:38PM -0500, Patrick Ouellette wrote:
> I did notice one anomaly that occurred frequently on the soundmodem
> diagnostic scope that I'm thinking might be signs of trouble.  In the
> capture, the line traced on the scope would occasionally draw a
> straight horizontal line within the signal at random places (both
> horizontally and vertically).  This "dead spot" seems to be uniformly
> about 4 1200 Hz cycles (~3 ms).  This does not seem to be clipping
> because it occurs at random levels.
> 
> Here is an excellent screen shot of the scope showing two instances of
> this anomaly in an otherwise pretty clean looking signal:
> 
> http://braddock.com/soundmodem.png
> 
> I'm wondering if this is a sampling problem with the ALSA i810 driver?
> If anyone could take a look at that scope image and let me know if
> that's normal behavior within the scope or a sound capture problem it
> would help us narrow this down.  It occurs at all sound levels AFAIK.
> 
> Also, I tried running soundmodem on a desktop system (vs my Inspiron
> laptop) that also has the Intel i810 sound chipset and ALSA drivers,
> with the exact same results.
> 
> All help much appreciated!
> 
> 	-Braddock Gaskill

Re: user soundmodem problems on Inspiron 8200 i810 chipset...

[Thomas Sailer]

braddock@braddock.com wrote:

> http://braddock.com/soundmodem.png
>

Looks like alsa tries to do sample rate conversion, but
"somewhat" imperfectly. Sigh. Does anyone know how to convince
ALSA to not do any sample rate conversion in their OSS emulation?

In the long run soundmodem probably should just use alsa natively.

Tom

Re: user soundmodem problems on Inspiron 8200 i810 chipset...

[Dave Platt]

> Looks like alsa tries to do sample rate conversion, but
> "somewhat" imperfectly. Sigh. Does anyone know how to convince
> ALSA to not do any sample rate conversion in their OSS emulation?

From what I can see, it looks as if ALSA tries to pick the "native"
rate supported by the card/chipset which is closest to the rate
being requested by the application.  There seems to be some logic
which will also accept a [sub?]multiple of the native "best" rate.

If the native rate is within 5% of the application-requested rate, 
then ALSA says "What the heck!" and passes the data through without
conversion.  Otherwise, the sample-rate-conversion plugin is 
inserted into the digital-signal chain.

The Intel 8x0 driver definition says that the driver supports
precisely one native sample rate - 48000 samples/second.  I
can't remember whether AC97 codecs are physically capable of
supporting any other sampling rate, and I don't know whether the
8x0 has a built-in hardware resampler.

There may be no way around having to do software-based resampling
on this chip (or on some others).  Whether it should be done by
ALSA in the kernel, or by the application, is probably a decision
which would depend on the application.

> In the long run soundmodem probably should just use alsa natively.

That's probably quite desireable, as the 2.6 kernel has switched
over to ALSA, and the OSS emulation does seem to have some
significant limits to it.

It might be worth considering adding support for the ALSA "JACK"
bus interface, in addition to (or instead of) doing low-level ALSA
calls.

Re: user soundmodem problems on Inspiron 8200 i810 chipset...

[Thomas Sailer]

On Wed, 2004-03-10 at 20:15, Dave Platt wrote:

> From what I can see, it looks as if ALSA tries to pick the "native"
> rate supported by the card/chipset which is closest to the rate
> being requested by the application.  There seems to be some logic

This is what OSS is supposed to do too. Soundmodem doesn't care much
about what sample rate is chosen in the end, it just needs to know to
update the filters correctly.

> which will also accept a [sub?]multiple of the native "best" rate.

which is not a good idea. This introduces aliasing distortion, and many
application just try to request one rate, trusting that the driver will
tell it if the hardware doesn't support it.

> The Intel 8x0 driver definition says that the driver supports
> precisely one native sample rate - 48000 samples/second.  I
> can't remember whether AC97 codecs are physically capable of
> supporting any other sampling rate, and I don't know whether the
> 8x0 has a built-in hardware resampler.

AC97 codec aren't required to support anything else than 48kHz, and
afaik the 8x0 doesn't have a hw sample rate converter.

> ALSA in the kernel, or by the application, is probably a decision
> which would depend on the application.

Soundmodem can do this itself. In fact it would prefer the driver to
just say what the hardware does, and that the driver doesn't try to be
too clever.

Tom

Re: user soundmodem problems on Inspiron 8200 i810 chipset...

[Braddock Gaskill KD5ZVK]

On Wed, Mar 10, 2004 at 06:44:43PM +0100, Thomas Sailer wrote:
> >http://braddock.com/soundmodem.png
> 
> Looks like alsa tries to do sample rate conversion, but
> "somewhat" imperfectly. Sigh. Does anyone know how to convince

The only strange thing about that theory (which I tend to agree
probably is what's going on) is that if I do a 9600 samp/sec capture
with SOX using the OSS interface, and look at the capture in Octave, I
don't see the anomaly.  In fact, I can then take the 9600 samp/sec SOX
capture of APRS input and use it with an unmodified version of
soundmodem in "file" mode and get perfect copy.

The command I'm using for the sox capture is:
sox -V -r 9600 -t ossdsp /dev/dsp -t wav -b -u -r 9600 /tmp/output4.wav
(or -t raw to look at it in Octave)

Now, a dmesg reveals an ALSA warning message when the snd-ac97-codec
module is inserted:
ALSA ../../alsa-kernel/pci/ac97/ac97_codec.c:1861: MC'97 1 converters and GPIO not ready (0xff00)

I don't know if that warning is related.

Sox (in -V verbose mode) outputs:
sox: Input file /dev/dsp: using sample rate 9600
        size bytes, encoding unsigned, 1 channel
sox: Input file /dev/dsp: comment "/dev/dsp"
sox: Writing Wave file: Microsoft PCM format, 1 channel, 9600 samp/sec
sox:         9600 byte/sec, 1 block align, 8 bits/samp
sox: Output file /tmp/output4.wav: using sample rate 9600
        size bytes, encoding unsigned, 1 channel
sox: Output file: comment "/dev/dsp"
sox: Finished writing Wave file, 17408 data bytes 17408 samples

At any rate, it's at least good to have these findings in the list
archives for others if nothing else.

	braddock gaskill (KD5ZVK)

Re: user soundmodem problems on Inspiron 8200 i810 chipset...

[Dave Platt]

> 
> The only strange thing about that theory (which I tend to agree
> probably is what's going on) is that if I do a 9600 samp/sec capture
> with SOX using the OSS interface, and look at the capture in Octave, I
> don't see the anomaly.  In fact, I can then take the 9600 samp/sec SOX
> capture of APRS input and use it with an unmodified version of
> soundmodem in "file" mode and get perfect copy.

My hunch is that the resampling problem may be triggered by the
way in which the soundmodem code specifies the number of DMA memory
buffers it wishes to use.  I've occasionally noticed problems in
applications (e.g. twpsk) which specify either very large, or
very small numbers of DMA buffer fragments, or very large or very
small fragment sizes.  OSS seems to try harder to guard against
ridiculously large or small fragment sizes or counts, while ALSA
seems to try harder to "do what the user says s/he wants".

It's possible that the fragment sizes or counts being
requested by the soundmodem code are resulting in the driver
running out of buffer space, or otherwise hitting a boundary
condition in its resampling code.

SOX probably doesn't try to specify DMA fragment sizes or
counts, allowing the driver defaults to apply, and these defaults
don't trigger the bug/limitation in the resampling code.

Re: user soundmodem problems on Inspiron 8200 i810 chipset...

[Dave Platt]

> The only strange thing about that theory (which I tend to agree
> probably is what's going on) is that if I do a 9600 samp/sec capture
> with SOX using the OSS interface, and look at the capture in Octave, I
> don't see the anomaly.  In fact, I can then take the 9600 samp/sec SOX
> capture of APRS input and use it with an unmodified version of
> soundmodem in "file" mode and get perfect copy.

It might be interesting to look and see what sorts of capture
parameters are actually being set up in the driver by each
of these two cases.

To do this, start a capture (either a SOX recording, or
run soundmodemconfig and open up the diagnostic scope),
and then try:

 cat /proc/asound/card0/pcm0c/sub0/hw_params

On my system (running the 1.0.2c ALSA drivers), this
shows a bunch of interesting information, including the
sample format. number of channels, native capture rate
(both as an integer, and as a numerator/denominator ratio
which I imagine is based on the hardware clock rate and
a divisor), buffer and period size, and processing tick
time.  It then provides much the same information for
the OSS compatibility layer.

If you can grab, and then post the results of this
for the SOX and soundmodem situations, it might give
further information about what might be making the
resampler go kerSPRUNG.

Re: user soundmodem problems on Inspiron 8200 i810 chipset...

[braddock]

On Wed, Mar 10, 2004 at 01:56:16PM -0800, Dave Platt wrote:
>  cat /proc/asound/card0/pcm0c/sub0/hw_params
> 
> If you can grab, and then post the results of this
> for the SOX and soundmodem situations, it might give

What a great little /proc tidbit.  

After looking at the hw_params stuff, I slightly modified my sox line
to capture 16-bit samples instead of 8-bit to better match soundmodem
(which captures in 16-bit).

sox -V -w -r 9600 -t ossdsp /dev/dsp -t wav -w -u -r 9600 /tmp/output6.wav

I recorded some APRS activity with this, then verified that soundmodem
in "file" mode would copy it from the captured wave file.  Worked
fine, I didn't see our anomaly.  I captured the /proc/../hw_params
data from this sox call, and from soundmodem (without my
sample rate hack), which showed the anomaly.  

The period/frame parameters vary by an order of magnitude between
them.  I don't know how to change these in sox, so I can't give a
better match (I'd LOVE to be able to reproduce the anomaly in sox so
we could file a reproducable bug report with the ALSA folks).

Here is /proc/../hw_params for the SOX call:
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 5115
buffer_size: 10230
tick_time: 10000
OSS format: S16_LE
OSS channels: 1
OSS rate: 9600
OSS period bytes: 2048
OSS periods: 2
OSS period frames: 5115

Here is /proc/../hw_params for soundmodemconfig in 1200 bps afsk scope mode:
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 639
buffer_size: 10224
tick_time: 10000
OSS format: S16_LE
OSS channels: 1
OSS rate: 9600
OSS period bytes: 256
OSS periods: 16
OSS period frames: 639

So, if someone tells me how to modify the period and buffer sizes in
soundmodem, I'll experiment and see if I can make the problem go away.

	-braddock

Re: user soundmodem problems on Inspiron 8200 i810 chipset...

[Tomi Manninen]

On Thu, 2004-03-11 at 01:41, braddock@braddock.com wrote:

> So, if someone tells me how to modify the period and buffer sizes in
> soundmodem, I'll experiment and see if I can make the problem go away.

It's the ioctl(SNDCTL_DSP_SETFRAGMENT) call in soundcard/audioio.c.
This is from the OSS Programmers Guide (pp. 97-98):

  int arg = 0xMMMMSSSS;
  ioctl(audio_fd, SNDCTL_DSP_SETFRAGMENT, &arg);

  The argument to this call is an integer encoded as 0xMMMMSSSS 
  (in hex). The 16 least significant bits determine the fragment 
  size. The size is 2^SSSS. For example SSSS=0008 gives fragment 
  size of 256 bytes (2^8). The minimum is 16 bytes (SSSS=4) and 
  the maximum is total_buffer_size/2. Some devices or processor
  architectures may require larger fragments - in this case the
  requested fragment size is automatically increased.

  ...

  The 16 most significant bits (MMMM) determine the maximum number 
  of fragments. By default, the driver computes this based on 
  available buffer space. The minimum value is 2 and the maximum 
  depends on the total buffer space available for the device. Set
  MMMM=0x7fff if you don't want to limit the number of fragments.

I don't think changing the fragment size is a solution though as it
affects the real-time preformance of soundmodem...

-- 
Tomi Manninen / OH2BNS / KP20ME04

Re: Compile warnings on hfterm with Mandrake

[Günther Montag]

Am Dienstag 09 März 2004 22:11 schrieb ravioli@softhome.net:
> A lot of warnings in the last release of hfterm-0.5 can be removed by
> applying this diff.
> More information on request.
> Remi F4ECW

tnx Remi!!
i forward it to hfterm hackers mailing list and
will work it into next release!
-- 
Günther Montag
Bahnhofstraße 15
D-86415 Mering
08233-32356
Safari.Doktor@addcom.de
-
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html