Cloudhub support for USB Wireless Adapters on Raspberry PI4B

Submitted by anomaly on #1

Hi Michael

I am trying to connect a VGA (640x480) webcam running at 30fps to stream from a clouddhub server (Raspberry PI4B hardware) to a remote PC.

It seems the performance of the onboard WIFI of the PI4B can only handle up to about 70~80Mbps. I can only get stable frames if I lower the frame rate to 15 fps.

I am thinking it could be solved if I connect my ALFA AWUS036ACM USB wifi adapter with 2T2R to the Pi4B . Unfortunately the cloudhub firmware doesn't seem to include the driver for this adapter so I am unable to test out this configuration.

Would it be possible to add a wlan1 interface to a cloudhub? or is there any other way I could test out the confiruration?

Thank You

Submitted by Michael on Tue, 2022/02/15 - 17:46

#2

No, cloudhub doesnt support that. You need to use raspbian and compile the driver for that

Submitted by anomaly on Tue, 2022/02/15 - 20:11

#3

Hi Michael

Thanks for the quick reply.

Just to verify the throughput of a raspberry pi4, I decided to set up raspbian and connect via an ethernet connection to remove all potential bottlenecks. This set up is unfortunately still only getting 70~80mbps at my PC when the camera is streaming

I have checked the usbfs and it is set at 1000, the CPU usage is also only at 10% or so.

I'm a bit stumped at this result as I was sure this would work and allow the full speed of the camera to be streamed.

The data rate I am after is around 180mbps. The camera stream is running at 640x480x2x30 = 18,432,000 bytes per second

Not sure where the bottleneck is.

Hope you can share your experiences

Thank You

Submitted by Michael on Tue, 2022/02/15 - 20:31

#4

In the virtualhere client right click USB Hubs->About->Statisitics

What sort of range does that show when you are using the camera via virtualhere?

Submitted by anomaly on Wed, 2022/02/16 - 12:35

#5

I am seeing latency spikes periodically from a baseline of around 1~2ms. The height of the spikes tend to be between 5ms and 70ms.

The throughput of ethernet is between 70 ~ 130Mbps. Still shy of the required 180Mbps

As before, vhusbdarm64 is only consuming 6%~10% CPU.

I have complete control over how the camera buffers data and how USB packets are sent over the bus if changing these can help.

Thank You

Submitted by Michael on Wed, 2022/02/16 - 15:24

#6

1-2ms is ok for video streaming. My guess is it is the latency of the network.

Thats quite useful if you can control the USB packets for your camera. If so can you keep multiple outstanding read requests on the isochronous endpoint. Virtualhere doesnt (yet) support URB_GET_ISOCH_PIPE_TRANSFER_PATH_DELAYS but you can see what you need to do regarding latency https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-cl….

Just try e.g pending 3 or more request on the isochronous endpoint and see if that improves things

Submitted by Michael on Wed, 2022/02/16 - 16:20

#7

Also another option is to post me the camera for a week or two and I can try to exactly determine where the bottleneck is

Submitted by anomaly on Fri, 2022/04/01 - 16:44

#8

Found the problem with the stuttering, here to update.

Our camera firmware was designed to run with an 8 node ring buffer to buffer video data as it comes in from the sensor. Each node is 16KB and when full, data is moved by DMA into the USB PHY for sending.

It turns out moving 16KB chunks regardless of the endpoint configuration (BULK or ISO) or running in USB 2.0 or USB 3.0 with varying packet sizes was causing issues. This amount of data was causing something to stutter on the raspberry PI4 side. I don't know why the Raspberry PI4 is unable to handle a burst of 16KB, but shortening the data burst solved the issue.

We have since set up a UVC burst of 3 x 1024 bytes, this is the maximum amount of data that can be handled each USB 2.0 micro-interval (125us) on a fully loaded ISOCHRONOUS endpoint.

Will need to do more testing, but looks promising for now

Submitted by Michael on Sat, 2022/04/02 - 16:21

#9

Thanks for letting me know

Submitted by anomaly on Mon, 2022/04/11 - 15:55

#10

After some testing, I am still stuck with a black screen when I replace the ethernet cable with wifi.

My set up

Camera is sending out a maximum of 3072 bytes per USB micro-interval. This works flawlessly when using ethernet.

My Wifi set up is as follows.
Raspberry Pi 4B with a AWUS036ACM USB 3.0 2T/2R wifi adapter (server)
PC with a AWUS036ACM USB 3.0 2T/2R wifi adapter. (client)

Raspberry Pi 4B is running hostapd and enumerates a soft access point, so I minimize the hops going from the Raspberry PI to the PC. It is essentially a 1-hop set up. Connection is 802.11ac using 80MHz channels. speed is 867mbit/867mbit.

Not really sure what else I can do. Either the Wifi fragmentation isn't working right or something is seizing up along the way.

thank you

Submitted by Michael on Mon, 2022/04/11 - 20:03

#11

In the virtualhere client, can you right click USB Hubs->About->Statistics and watch the latency. What does that generally show?

Also if you *only use the inbuilt wifi* does that work ?

Submitted by anomaly on Thu, 2022/04/14 - 16:08

#12

Fixed the issue with the black screen

Turns out my camera buffer was under running, data was overwritten before it had the chance to be moved out. Increasing the number of ring buffer nodes solved the issue. This indicates there are some fundamental differences between the ethernet stack and wifi stacks.

With regard to latency, in wifi mode, if the link is steady, it is between 3-10ms and the image is very steady. But it can spike to 30ms or higher often and sometimes it happens in sequence. Is there a way to stabilize the wifi link?

thank you

Are there any tips

Submitted by Michael on Thu, 2022/04/14 - 17:25

#13

Yes you may get underruns because wifi latency is quite variable. Ethernet latency is of course much more stable.

VirtualHere will always transfer all the data and not skip anything regardless of the medium.

So if the data is delayed by latency in the network it will arrive late but it will arrive.

If it does not arrive the device will be virtually disconnected. Its a bit complicated but basically URBs must always be acknowledged at the lower level. If they cannot be acked then virtualhere will complete them with "device disconnected" status after about 12sec. And they wont be retried. USB doesnt have retries

My tip for figuring out latency spikes is to basically use top

If some other process jumps to the top when latency occurs then i recommend using nice to force priority of the vhusbd process