Audio Dropouts

_John_WB5NFC · December 13, 2009, 8:03pm

Audio dropouts seem to be happening more often on my node. I was monitoring an IRLP QSO today while watching console output. Most severe dropouts occurred during the WARNINGS shown below. The DTMF chars appear to be falsing - no tones were sent.

Suggestions on troubleshooting appreciated.

    -- Hungup 'Zap/pseudo-271255635'
    -- Hungup 'Zap/pseudo-102441634'
    -- Hungup 'Zap/pseudo-1965758556'
[Dec 13 13:18:10] WARNING[9819]: channel.c:2590 ast_prod: Prodding channel 'Zap/pseudo-1412454098' failed
    -- Hungup 'Zap/pseudo-1412454098'
[Dec 13 13:18:10] WARNING[9823]: file.c:602 ast_openstream_full: File none does not exist in any format
[Dec 13 13:18:10] WARNING[9823]: file.c:912 ast_streamfile: Unable to open none (format 0x44 (ulaw|slin)): No such file or directory
[Dec 13 13:18:10] WARNING[9823]: app_rpt.c:6348 sayfile: ast_streamfile none failed on Zap/pseudo-972989682
    -- Hungup 'Zap/pseudo-972989682'
    -- Hungup 'Zap/pseudo-1265443263'
    -- Hungup 'Zap/pseudo-745980955'
[Dec 13 13:18:27] NOTICE[2485]: chan_usbradio.c:2413 usbradio_read: Got DTMF char 1
[Dec 13 13:18:27] NOTICE[2485]: chan_usbradio.c:2413 usbradio_read: Got DTMF char 2
[Dec 13 13:18:34] NOTICE[2485]: chan_usbradio.c:2413 usbradio_read: Got DTMF char 1
    -- Hungup 'Zap/pseudo-1140470725'
    -- Hungup 'Zap/pseudo-1190238186'
[Dec 13 13:19:38] WARNING[2485]: chan_usbradio.c:2117 usbradio_read: Possibly stuck USB read channel. [usb1]
[Dec 13 13:19:38] ERROR[2485]: chan_usbradio.c:2111 usbradio_read: Stuck USB read channel [usb1], un-sticking it!
  == Set device 3-1 to usb1
  == Parsing '/etc/asterisk/usbradio_tune_usb1.conf': Found
[Dec 13 13:19:42] WARNING[2487]: chan_usbradio.c:1436 hidthread: Loaded parameters from usbradio_tune_usb1.conf for device usb1 .
[Dec 13 13:19:42] NOTICE[2487]: chan_usbradio.c:1491 hidthread: USB Adapter has no EEPROM installed or Checksum BAD on channel usb1
    -- Hungup 'Zap/pseudo-381069940'
    -- Hungup 'Zap/pseudo-772603506'
    -- Hungup 'Zap/pseudo-189122681'
    -- Hungup 'Zap/pseudo-1925009327'
    -- Hungup 'Zap/pseudo-622652136'
    -- Hungup 'Zap/pseudo-1997606468'
    -- Hungup 'Zap/pseudo-60672029'
  == Set device 3-1 to usb1
  == Parsing '/etc/asterisk/usbradio_tune_usb1.conf': Found
[Dec 13 13:20:18] WARNING[2487]: chan_usbradio.c:1436 hidthread: Loaded parameters from usbradio_tune_usb1.conf for device usb1 .
[Dec 13 13:20:19] NOTICE[2487]: chan_usbradio.c:1491 hidthread: USB Adapter has no EEPROM installed or Checksum BAD on channel usb1
    -- Hungup 'Zap/pseudo-606552813'
[Dec 13 13:20:52] WARNING[2485]: chan_usbradio.c:2117 usbradio_read: Possibly stuck USB read channel. [usb1]
[Dec 13 13:20:52] ERROR[2485]: chan_usbradio.c:2111 usbradio_read: Stuck USB read channel [usb1], un-sticking it!
  == Set device 3-1 to usb1
  == Parsing '/etc/asterisk/usbradio_tune_usb1.conf': Found
[Dec 13 13:20:55] WARNING[2487]: chan_usbradio.c:1436 hidthread: Loaded parameters from usbradio_tune_usb1.conf for device usb1 .
[Dec 13 13:20:55] WARNING[2485]: chan_usbradio.c:2117 usbradio_read: Possibly stuck USB read channel. [usb1]
[Dec 13 13:20:55] WARNING[2485]: chan_usbradio.c:2120 usbradio_read: Nope, USB read channel [usb1] wasn't stuck after all.
    -- Hungup 'Zap/pseudo-1810467925'
[Dec 13 13:20:55] NOTICE[2487]: chan_usbradio.c:1491 hidthread: USB Adapter has no EEPROM installed or Checksum BAD on channel usb1
[Dec 13 13:20:57] NOTICE[2357]: chan_echolink.c:1770 sendcmd: Received OK from Echolink server server1.echolink.org
[Dec 13 13:21:04] NOTICE[2357]: chan_echolink.c:2102 do_el_directory: Directory pgm done downloading(partial,compressed), 131 records
[Dec 13 13:21:04] NOTICE[2478]: chan_irlp.c:1138 irlp_reader: received IRLP bye from 74.194.190.143
    -- Hungup 'Zap/pseudo-1253550486'

John / WB5NFC

n8lbv · December 13, 2009, 9:05pm

My status is still at a point where I'm trying to get a good handle on being able to compile some custom Linux kernels that work..
I have some brushing up and getting up to date to do on this as my last few attempts have not produced a working kernel yet..

I need to be able to do this in order to at least try the semi-fixes that Dave suggests by using his modified code as well as using relaxed DTMF decoding...

I've thoroughly convinced myself that there are issues with intermittent dropouts / intermittent choppy audio on all systems I have tested
regardless of CPU speed motherboard chipset, integrated video/USB etc. etc.

I will update when I have a chance to try my custom kernels and Dave's posted fixes

For anyone questioning these dropout issues I'd be happy to work with you live and give you an over the Internet live audio feed
physically patched to the audio output of any of my test systems where you can hear the audio intermittently chopping out while we look at live events and live debug data.

The way I am testing (which makes all of the dropouts far more obvious and detectable) is by running the audio output from the USB fob to a good set of amplified speakers..
setting TX timeout very high issuing a radio key and listening the the transmitted PL tone as well as a CWID beacon sent every 60 seconds (you get used to it.)

The audio dropouts are prevalent as ever on every system I've tested so far which specifically includes:

* Pentium3 450Mhz all Intel chipset.
* Pentium3 600Mhz Intel chipset
* AMD Duron 1.1Ghz all in oue mother board system VIA chipset.

* AMD Athlon64 system NVidia motehrbaord (NForce3) with AGP Nvidia video card.
* Intel Core2 Quad 6700 Nvidia SLI750i motherboard with Nvidia PCI/e video card

* Intel i5 (2.66Ghz) Asus P7P55D Motherboard (Intel P55 Express chipset) woth PCI/e video card.

* AMD Turion64 Laptop (2.2Ghz CPU) also tried turning off speedstep locking CPU at full speed.

* HP Laptop with Intel P4 3.2Ghz (Single core) CPU Intel chipset.

* Virtual Machine on AMD Turion Laptop: has same audio dropouts + it's own new audio pops due to virtual machine/usb share (this is expected)

I've noticed the frequency of the dropouts on all systems to be about the same.. but the 'sound' of the droputs changes
with CPU speed... on the very slow systems you can actually hear the 'putter putter putter' sound they make..
On very fast systems you hear a quick 'zipping sound'.

This occurs seeming randomly but on average 3-5 times in any 3 minute span of time..
Especially around the beginning and end of the CWID but not always there..

At this point I'm speculating (but I'm not an expert or software/driver guy) that the routine handling sending data to the USB
fob is being inappropriately interrupted by something else (or everything else) when it should not be..
In my experience this routine should have some type of exclusive (or nearly exclusive) use of the CPU/bus while the data is being sent
(timer interrupt routine I am guessing) to the USB device.

Thanks!

Steve N8LBV

···

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.