user soundmodem problems on Inspiron 8200 i810 chipset...

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

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

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);

---

302c298
< void * m = NULL;
---

525c521
< void *m = NULL;
---

646c642
< if ( (!fragptr) && ( m!= NULL) ) 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); */
---

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
---

diff --recursive hf-0.5/proto/pactor.c hf-0.5.ORG/proto/pactor.c 1020c1020
< #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>

Am Dienstag 09 März 2004 22:11 schrieb [email protected]:

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
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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

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

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.

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.

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 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.

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

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

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)

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.

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.

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

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