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
.
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?
Hello,
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
More information for you:
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.
And one more bit of info:
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
.
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...
The crackle is noticeably
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.