PTT with soundmodem

Hi all,

I'm thiiis close to having my packet set up working in kernel 2.4.24 (currently unpatched). I'm using the user space soundmodem to create interface ax0 -- so I assume I don't need to do a kissattach. When I use soundmodemconfig to test the setup, I can successfully use the PTT gui button to get my rig to transmit (and also have no problem with PTT when using Tomi's great gMFSK!). However, while i can receive APRS packets while running xastir, when it tries to transmit, soundmodem complains after the xastir info:

Tx: fm AB3AP-0 to APX121-0 via RELAY-0,WIDE-0 UI^ pid=F0 =/:B7_;?z&y [email protected], Avondale PA (XASTIR-Linux)

sm[15891]: ioctl: SNDCTL_DSP_SYNC: Device or resource busy (16)

I see the LED on my PTT interface briefly light, but not long enough to activate the rig itself before the error above is printed.

I use the same HW addr (AB3AP-1) in my soundmodem.conf as in my /etc/ax25/axports file. Anyone spot what I'm doing wrong? I haven't included any .conf files since I'm not at that machine now and am hoping the above description is enough to indicate my mistake, but I'll be happy to go get those if needed. Thanks for any ideas!

Mike AB3AP

Do you have any other programs at all accessing the sound card? Things like the sound server for KDE or GNOME?

Is AX.25 working properly in 2.4.24? I was under the impression that it was never reliable in 2.4, and fixes are going straight to 2.6. I'm still running 2.2 on my packet machine.

Hamish

Hamish Moffatt VK3SB <[email protected]> <[email protected]>

I am using userspace soundmodem on my old P-100 laptop with Xastir and kernel 2.4.16 and SuSE 7.3. Works great. I use the parallel port for PTT.

Which version of soundmodem are you using and which interface for PTT??

Mike Fenske
VE7MKF

The SNDCTL_DSP_SYNC call is supposed to cause the driver to wait until all samples buffered to the soundcard are actually written to the output. This is done at the end of each transmission so that soundmodem knows when it can release the PTT and switch to RX.

For some reason this now fails and then PTT is released immediately. Unfortunately the only cause for the failure I can think of, is a poorly written sound card driver (I could be wrong though -- what is your card btw?).

You could try forcing the driver to half duplex (in the IO tab in soundmodemconfig) and see if that fixes it. That is not a good solution though as it can cause additional latency in tx/rx switching (bad for CSMA performance).

Another remedy might be trying the ALSA driver.

(And FWIW, gMFSK uses the same technique to time PTT switching, but as latencies are not nearly as important in gMFSK, I can always use half duplex audio IO. That tends to be fool (and poor driver) proof... :)

Tomi Manninen / OH2BNS / KP20ME04

Thanks, guys, for the replies to my note.

I don't really know. Though I'm certainly willing to a new kernel - and especially if any new soundcard drivers are included! (See below.)

I currently use the serial port for PTT (but will soon switch to parallel so I can have rig control on the serial). And I compiled soundmodem-0.7 from source.

That might be the problem. I'm using a several-year-old HP Omnibook XE3 laptop from work. It has an ESS Maestro3 soundcard, which is labeled as Experimental in the kernel config sound menu.

I gave it a try, and it keeps the PTT asserted long enough to trigger the rig now, but still just briefly and I get the same error.

Ok, I'll go to the ALSA website and read up on it, since I've never played with that. I'm hoping I can stick with the laptop, but we'll see how it goes... Thanks for the help!

Mike AB3AP

Hi,

When loading soundmodem or baycomepp the mkiss and ax25 modules are
loaded, ax0 interface is created. So far so good. When stopping the user-space application and restarting it some time later, the application stalls, ifconfig stalls ... and kernel error is logged:

Feb  6 19:06:11 xyz kernel: NET: Registered protocol family 3
Feb  6 19:06:11 xyz kernel: mkiss: AX.25 Multikiss, Hans Albas PE1AYX

Feb  6 19:08:10 xyz kernel: ------------[ cut here ]------------
Feb  6 19:08:10 xyz kernel: kernel BUG at net/core/dev.c:2703!
Feb  6 19:08:10 xyz kernel: invalid operand: 0000 [#1]
Feb  6 19:08:10 xyz kernel: CPU:    0
Feb  6 19:08:10 xyz kernel: EIP:    0060:[<c0220419>]    Not tainted
Feb  6 19:08:10 xyz kernel: EFLAGS: 00210202
Feb  6 19:08:10 xyz kernel: EIP is at register_netdevice+0x61/0x1e4
Feb  6 19:08:10 xyz kernel: eax: 00000001   ebx: cf12a058   ecx: c0308d40 
 edx: 00000000
Feb  6 19:08:10 xyz kernel: esi: 00000001   edi: cf12a058   ebp: cf12a000 
 esp: c8c6fe8c
Feb  6 19:08:10 xyz kernel: ds: 007b   es: 007b   ss: 0068
Feb  6 19:08:10 xyz kernel: Process soundmodem (pid: 1043,
threadinfo=c8c6e000 task=cef34cc0)
Feb  6 19:08:10 xyz kernel: Stack: cf12a058 00000001 cf12a058 cf12a000
c01fa1ea cf12a058 cf12a058 c9bfc000
Feb  6 19:08:10 xyz kernel:        00000000 d09ec7d5 cf12a058 c9bfc00c
c038b538 c9bfc050 c9bfc000 c01d6883
Feb  6 19:08:10 xyz kernel:        c9bfc000 bffff8e4 c9bfc000 0000001a
c9c04000 00000050 00000000 00000000
Feb  6 19:08:10 xyz kernel: Call Trace:
Feb  6 19:08:10 xyz kernel:  [<c01fa1ea>] register_netdev+0x5e/0x70
Feb  6 19:08:10 xyz kernel:  [<d09ec7d5>] ax25_open+0xdd/0x16c [mkiss]
Feb  6 19:08:10 xyz kernel:  [<c01d6883>] tty_set_ldisc+0x133/0x220
Feb  6 19:08:10 xyz kernel:  [<c01dc95b>] set_termios+0x197/0x1a4
Feb  6 19:08:10 xyz kernel:  [<c01db82c>] n_tty_open+0x0/0x94
Feb  6 19:08:10 xyz kernel:  [<c01db800>] n_tty_close+0x0/0x2c
Feb  6 19:08:10 xyz kernel:  [<c01d9d08>] n_tty_flush_buffer+0x0/0x40
Feb  6 19:08:10 xyz kernel:  [<c01d9d48>] n_tty_chars_in_buffer+0x0/0x6c
Feb  6 19:08:10 xyz kernel:  [<c01db8c0>] read_chan+0x0/0x8ac
Feb  6 19:08:10 xyz kernel:  [<c01dc16c>] write_chan+0x0/0x1f8
Feb  6 19:08:10 xyz kernel:  [<c01dcb2c>] n_tty_ioctl+0x0/0x3f4
Feb  6 19:08:10 xyz kernel:  [<c01db650>] n_tty_set_termios+0x0/0x1b0
Feb  6 19:08:10 xyz kernel:  [<c01dc364>] normal_poll+0x0/0x134
Feb  6 19:08:10 xyz kernel:  [<c01da614>] n_tty_receive_buf+0x0/0x1000
Feb  6 19:08:10 xyz kernel:  [<c01da5ac>] n_tty_receive_room+0x0/0x38
Feb  6 19:08:10 xyz kernel:  [<c01da5e4>] n_tty_write_wakeup+0x0/0x30
Feb  6 19:08:10 xyz kernel:  [<c01d8bf4>] tiocsetd+0x18/0x24
Feb  6 19:08:10 xyz kernel:  [<c01d9047>] tty_ioctl+0x2ef/0x3d4
Feb  6 19:08:10 xyz kernel:  [<c015e979>] sys_ioctl+0x209/0x260
Feb  6 19:08:10 xyz kernel:  [<c010af2f>] syscall_call+0x7/0xb
Feb  6 19:08:10 xyz kernel:
Feb  6 19:08:10 xyz kernel: Code: 0f 0b 8f 0a 63 c1 2a c0 8b 43 2c c7 83

24 01 00 00 ff ff ff

Thus the second time the user-space soundmodem does call register_netdev there is this error. As far as I can remember rmmod'ing mkiss and ax25 between the first and second run of soundmodem did not help.

Results are identical for 2.6.0 and .1 and .2
The .config file I used came from www.backports.org/debian. The current used ( for 2.6.2 ) can be found at http://users.pandora.be/nespa/kernoops

Is there some dependency I missed, either inside our outside kernel ?

Thanks in advance.

Leo, on1aad

--
wake up-what's in that room, wake up- what's in that house? King Ink

You are missing a few patches to fix the reuse of network devices in mkiss. (it appears 6pack has it to, I will probably post a fix for it soon) The patch for mkiss is included in 2.6.2-bk2

Jeroen

Tomi,

You were exactly right!

I read up on ALSA et al., downloaded the software, and started to compile. Only then did I download kernel 2.6.1 and discover ALSA drivers are now in the kernel. Doh! Anyway, I cranked up xastir after rebooting with the new kernel and starting soundmodem, and everything is working fine! Seeing acks come back from my aprs messages really capped off the effort. So now that everything is working...I have to learn what other applications are available on packet. :-)

Thanks very much for the help getting my laptop "packeting."

Mike AB3AP