AMB82-mini Client.write - 1 to 4-second pauses

Technical Discussion
1

I’ve written a multi-client video-JPEG stream web server (a little one) for the AMB82-MINI. It works pretty well, but the video feed gets pretty jerky.

client.write(buf, len); where client is of type WiFiClient seems to randomly insert 1 to 4 second pauses in the stream where it should be writing JPEG frames.

I’ve found this by profiling my code, and traced it down to client.write(buf,len), but I don’t have visibility into this code to further diagnose.

I’m seeing errors of type:
[Driver]: skb_unavailable=6 in last 2 seconds
but they don’t appear closely correlated to these pauses. The errors occasionally show up after the pauses.

Can anyone tell me what would make the stream choke like this? All the frames before and after seem to be delivered rapidly and correctly.

2

Further investigation shows that these pauses only occur when what’s being written is the image from the camera (not the IMG_HEADER or the STREAM_BOUNDARY text items).

When these pauses occur, I’m sending sendChunk(client, (uint8_t*)img_addr, img_len); from the camera, where img_addr is the address of the frame to send, and img_len is the length of the frame. The paused frames are not notably long. The pauses don’t corrolate with the skb_unavailable errors.

void CameraView::sendChunk(WiFiClient& client, uint8_t* buf, uint32_t len) {
    uint8_t ch_buf[64] = {0};
    uint8_t ch_len = snprintf((char*)ch_buf, 64, "%lX\r\n", len);
    client.write(ch_buf, ch_len);
    client.write(buf, len);
    client.print("\r\n");
}

I’ve removed a lot of junk data from the serial stream below - the frames that go right, the endless "ERROR] get_available Accept connection failed"messages that come when the server is not set to blocking mode - and an example log of the long pauses is below.

prof_b is the time in milliseconds it took `client.write(buf, len); to execute, and

prof_c is the size of the JPEG frame in bytes.

typically (in “working” frames without an extra pause), prof_b takes 4 milliseconds, in rare cases up to 10. Unless it’s in an extra pause, shown below. The pauses can reach into the 4,000 milliseconds. During these extra pauses, there’s a noticeable hiccup in the video stream.

I’ve forced the AMB82-MINI to 5GHz WiFi (by filtering the MAC address off my 2.4GHz - verified by looking at the device connections in my router). Still seeing pauses upon frame write.

prof_b: 1299, prof_c: 39807
[Driver]: skb_unavailable=2 in last 2 seconds
[Driver]: skb_unavailable=24 in last 2 seconds
[Driver]: skb_unavailable=28 in last 2 seconds
[Driver]: skb_unavailable=29 in last 2 seconds
[Driver]: skb_unavailable=30 in last 2 seconds
[Driver]: skb_unavailable=24 in last 2 seconds
[Driver]: skb_unavailable=21 in last 2 seconds
[Driver]: skb_unavailable=9 in last 2 seconds
prof_b: 931, prof_c: 34075
[Driver]: skb_unavailable=21 in last 2 seconds
[Driver]: skb_unavailable=26 in last 2 seconds
[Driver]: skb_unavailable=23 in last 2 seconds
prof_b: 1104, prof_c: 39920
[Driver]: skb_unavailable=5 in last 2 seconds
[Driver]: skb_unavailable=3 in last 2 seconds
[Driver]: skb_unavailable=6 in last 2 seconds
prof_b: 1277, prof_c: 31087
[Driver]: skb_unavailable=1 in last 2 seconds
[Driver]: skb_unavailable=21 in last 2 seconds
[Driver]: skb_unavailable=17 in last 2 seconds
[Driver]: skb_unavailable=12 in last 2 seconds
[Driver]: skb_unavailable=12 in last 2 seconds
prof_b: 1122, prof_c: 31790
[Driver]: skb_unavailable=8 in last 2 seconds
[Driver]: skb_unavailable=14 in last 2 seconds
prof_b: 996, prof_c: 43989
3

Tried yesterday on a different network: a 5GHz phone hotspot. Same result: random pauses, potentially more than on the local wifi network.

The web service looks tied to the WiFi client - were there a way to use the OTG port as a wired bridge to network, I suppose I still couldn’t eliminate WiFi as a culprit. Am I thinking straight there?