Audio crackle/static on Icom IC-7100 USB audio connection

Submitted by ag7gn on #1

Hello,

I have an Icom IC-7100 ham radio connected via USB to a Raspberry Pi 3 B running the latest firmware. I'm using the Pi-optimized Virtualhere server (3.3.5) on the Pi. The USB connection from the Icom presents 3 devices to the Pi: Serial port A, serial port B, and an audio codec. This is lsusb output from the pi:

Bus 001 Device 009: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
Bus 001 Device 008: ID 08bb:2901 Texas Instruments PCM2901 Audio Codec
Bus 001 Device 007: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light
Bus 001 Device 006: ID 0451:2046 Texas Instruments, Inc. TUSB2046 Hub

lsusb -t indicates that these are all USB v1 devices, if that matters.

pi@creekside-pi:/var/log $ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
|__ Port 3: Dev 5, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
|__ Port 5: Dev 6, If 0, Class=Hub, Driver=hub/4p, 12M
|__ Port 1: Dev 7, If 0, Class=Vendor Specific Class, Driver=cp210x, 12M
|__ Port 2: Dev 8, If 2, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 2: Dev 8, If 0, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 2: Dev 8, If 3, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 2: Dev 8, If 1, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 3: Dev 9, If 0, Class=Vendor Specific Class, Driver=cp210x, 12M

The Pi connects to my clients via a private point-to-point 5GHz wireless connection about 200 feet away. I've tested 2 clients (Windows 10 and Ubuntu 16.04 LTS) running the latest virtual here client software. Virtualhere traffic is the only thing on this wireless network. I see no packet loss or retransmissions or fragmentation on either end using Wireshark, and the wireless link is only about 2% utilized at most.

On the clients, I run a ham radio app called Fldigi, which allows the radio to communicate using several digital modes. Fldigi uses 1 of the 2 serial ports and the audio codec to carry received and transmitted audio between the software and the radio. The serial connection, which controls the operation of the radio @ 19200bps, works very well. However, when I transmit, the audio I hear over the air contains an audible "crackle" or "static", rendering the digital communication unintelligible to the receiver's ears (other hams have reported this tom me, too). When I connect either the Win10 or Ubuntu client directly to the USB cable from the radio, it works fine - no audible crackle at all.

The Pi is running the GUI and VirtualHere - nothing else. It's CPU is under 5% on average, and I see no packet loss on the ethernet interface. I'm using the wired interface on the Pi, by the way. I have disabled the Pi's Wifi.

Any ideas what this might be?

Thanks,

Steve

Submitted by Michael on Wed, 2017/06/21 - 12:44

#2

Its probably network latency, for a test can you connect your client to the network via a LAN cable instead of wifi. Are the crackles mostly gone now?

Submitted by ag7gn on Thu, 2017/06/22 - 02:13

#3

Hello,

Per your recommendation, I just connected the client to the same switch as the server (bypassing the wireless network entirely), and the crackles are still there. I tried both a Raspberry Pi client and an Ubuntu 16.04 LTS client. Both have the audio problem when connected to the same switch as the server.

Thanks,
Steve

Submitted by ag7gn on Thu, 2017/06/22 - 03:13

#4

More information for you:

When I start my fldigi application on the client (which is also running the VirtualHere client), these messages appear in syslog on the Virtual Here (VH) server:

Jun 21 17:05:31 creekside-pi vhusbdarmpi3[4404]: Error 22 discarding urb 0x225a630 for device /sys/bus/usb/devices/1-1.5.2, Invalid argument (abort endpoint)
Jun 21 17:05:31 creekside-pi vhusbdarmpi3[4404]: Error 22 discarding urb 0x225a4b0 for device /sys/bus/usb/devices/1-1.5.2, Invalid argument (abort endpoint)
Jun 21 17:05:31 creekside-pi vhusbdarmpi3[4404]: Error 22 discarding urb 0x222b2b0 for device /sys/bus/usb/devices/1-1.5.2, Invalid argument (abort endpoint)
Jun 21 17:05:32 creekside-pi vhusbdarmpi3[4404]: Error 22 discarding urb 0x222b440 for device /sys/bus/usb/devices/1-1.5.2, Invalid argument (abort endpoint)
Jun 21 17:05:32 creekside-pi vhusbdarmpi3[4404]: Error 22 discarding urb 0x2249130 for device /sys/bus/usb/devices/1-1.5.2, Invalid argument (abort endpoint)
Jun 21 17:05:32 creekside-pi vhusbdarmpi3[4404]: Error 22 discarding urb 0x226aef0 for device /sys/bus/usb/devices/1-1.5.2, Invalid argument (abort endpoint)
Jun 21 17:05:32 creekside-pi vhusbdarmpi3[4404]: Error 22 discarding urb 0x222b180 for device /sys/bus/usb/devices/1-1.5.2, Invalid argument (abort endpoint)
Jun 21 17:05:32 creekside-pi vhusbdarmpi3[4404]: Error 22 discarding urb 0x222b380 for device /sys/bus/usb/devices/1-1.5.2, Invalid argument (abort endpoint)
Jun 21 17:05:32 creekside-pi vhusbdarmpi3[4404]: Error 22 discarding urb 0x2249cc0 for device /sys/bus/usb/devices/1-1.5.2, Invalid argument (abort endpoint)
Jun 21 17:05:32 creekside-pi vhusbdarmpi3[4404]: Error 22 discarding urb 0x2248100 for device /sys/bus/usb/devices/1-1.5.2, Invalid argument (abort endpoint)
Jun 21 17:05:32 creekside-pi vhusbdarmpi3[4404]: Error 22 discarding urb 0x2248300 for device /sys/bus/usb/devices/1-1.5.2, Invalid argument (abort endpoint)
Jun 21 17:05:32 creekside-pi vhusbdarmpi3[4404]: Error 22 discarding urb 0x222b230 for device /sys/bus/usb/devices/1-1.5.2, Invalid argument (abort endpoint)

These messages only appear when the fldigi app starts, though - not while operating (transmitting or receiving).

The VH client looks like this:

pi@condo-pi:~/Downloads $ sudo ./vhclientarmhf -t list
VirtualHere Client IPC, below are the available devices:
(Value in brackets = address, * = Auto-Use)

(condo-pi:7575)
Raspberry Hub (creekside-pi:7575)
--> USB Audio CODEC (creekside-pi.1152) (In-use by you)
--> IC-7100 02007519 A (creekside-pi.1151) (In-use by you)
--> IC-7100 02007519 B (creekside-pi.1153)
--> RTS01 Radio Cable (creekside-pi.113)

Auto-Find currently off
Auto-Use All currently off
Reverse Lookup currently off
VirtualHere Client is running as a service
pi@condo-pi:~/Downloads $

creekside.1152 is a serial connection that allows the fldigi application to control the ham radio. That works fine. It's just the audio crackle that's causing problems.

Submitted by ag7gn on Thu, 2017/06/22 - 04:08

#5

And one more bit of info:

I read elsewhere that sometimes forcing the USB hub in the Pi to 1.1 makes it work better with USB v1 devices (which these are), so I added dwc_otg.speed=1 to /boot/cmdline.txt. No difference. Crackle is still present.

BEFORE I added I added dwc_otg.speed=1 to /boot/cmdline.txt:

pi@creekside-pi:~ $ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
|__ Port 3: Dev 4, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
|__ Port 5: Dev 5, If 0, Class=Hub, Driver=hub/4p, 12M
|__ Port 1: Dev 6, If 0, Class=Vendor Specific Class, Driver=cp210x, 12M
|__ Port 2: Dev 7, If 2, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 2: Dev 7, If 0, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 2: Dev 7, If 3, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 2: Dev 7, If 1, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 3: Dev 8, If 0, Class=Vendor Specific Class, Driver=cp210x, 12M
pi@creekside-pi:~ $ sudo /home/pi/vhusbdarmpi3 -b

AFTER I added dwc_otg.speed=1 to /boot/cmdline.txt:

pi@creekside-pi:~ $ lsusb -t
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 12M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 12M
|__ Port 3: Dev 4, If 0, Class=Vendor Specific Class, Driver=ftdi_sio, 12M
|__ Port 5: Dev 5, If 0, Class=Hub, Driver=hub/4p, 12M
|__ Port 1: Dev 6, If 0, Class=Vendor Specific Class, Driver=cp210x, 12M
|__ Port 2: Dev 7, If 2, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 2: Dev 7, If 0, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 2: Dev 7, If 3, Class=Human Interface Device, Driver=usbhid, 12M
|__ Port 2: Dev 7, If 1, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 3: Dev 8, If 0, Class=Vendor Specific Class, Driver=cp210x, 12M

Submitted by Michael on Thu, 2017/06/22 - 18:57

#6

Im not sure what else to try, virtualhere should work ok with audio/mic (there would be some static but not much), it all depends on the network latency.

My best guess is that the audio is delayed very slightly due to the latency in the network and this is enough to throw out the timings on the audio capture just enough to confuse the driver...

Submitted by ag7gn on Fri, 2017/06/23 - 08:31

#7

The crackle is noticeably less when the VH client and server are connected to the same switch, but ANY crackle into the audio codec will, unfortunately, wreak havoc on digital modes in amateur radio. I think you are correct that it is due to network latency, but I hadn't expected it to be quite so sensitive. There's no way to adjust the sound card settings in the radio itself, though.

I've found a workaround by using X forwarding over SSH into the Pi from my Mac and running the fldigi app on the Pi that's connected directly via USB to the radio. That works fine, as does using VNC to the Pi. It's not the solution I was hoping for, but it'll do for now.