Android Question Bluetooth or screen draw speed - Android 10 vs older Android

[Arf]

I receive streamed data by bluetooth and draw it to a graph onscreen.
Speed was always fine on my old 2014 Nexus running android 6. I have (what I believe to be) a more powerful device running Android 10 - a google Pixel.
On the Pixel, the graph drawing is laggy, I can see that the device sometimes doesn't hit the DataReceived event for more than 500ms, while I know the transmitting device is sending small packets much more often.

Is there any precedence for this, or any suggestions as to what I can try do to improve this?

 

[Erel]

Are you using AsyncStreams in prefix mode?

Does it behave differently if the device is charged?

 

[Arf]

I use Asyncstreams, but not in prefix mode. I usually have it plugged in when developing so usually around full charge.

 

[Erel]

This means that the buffering happens in a lower level. Not something that you can configure.

 

[agraham]

If absolute real time is not required then you could add your own one or two seconds of buffering to keep the stream continuous.

 

[Erel]

Good idea. You can use B4XBytesBuilder (B4XCollection) to implement such buffer.

 

[Arf]

Thanks, so do you mean implement a buffer to collect incoming data, and my activity grabs the samples from that buffer?
I've already got that. In AStream_NewData, I first stuff data in the buffer with this function:

Public Sub PutManyByte(rxd() As Byte)
    For i =0 To rxd.Length-1
        fifobuf.Add(rxd(i))
        'Log("rx: " & rxd(i))
        rxdCnt = rxdCnt+1
    Next
End Sub

Then before leaving the AStream_NewData, I check if the amount of data in 'fifobuf' is sufficient to contain one or more packets of my data, and if it does I repetitively retrieve the packets out of fifobuf and send them to a function in my activity that draws to screen and so on.

I guess I should not be doing this last part in the AStream_NewData event but rather in a timer event in my activity? I'll give that a go.

For interest sake, here's the sort of lag I am seeing - up to 3.7 seconds in this captured data:

 

[Erel]

You shouldn't do anything in the activity. Switch to B4XPages and many things will be simpler.

Your code will be slow in debug mode. Make sure to test it in release mode.
It will be faster and better to use B4XBytesBuilder.
You must use a timer.

 

[agraham]

For interest sake, here's the sort of lag I am seeing - up to 3.7 seconds in this captured data:

That looks odd to me. From your initial description I assumed that instead of lots of DataReceived events with small amounts of data you were getting fewer DataReceived events with more data, implying that the later Android version is doing more buffering before raising the event. That should imply a more or less constant maximum delay but those figures show the delay increasing with each packet. Are you sure you are measuring what you think you are measuring?

 

[Arf]

You're right, the 'received time' is the time that a complete packet is pulled out of the buffer so it would be subject to all the delays introduced by my processing of each sample. I'll try and disable screen drawing and certain processing to find if suddenly the problem improves.
Here's the same output on my Nexus 7:

The negative figures are just because the timing between tx and rx are subject to an arbitary delay in the first place which I am simply subtracting out, but obvs whatever issue exists on the Pixel is not affecting the Nexus, and I don't have any other Android 10 devices to try and se if it is device specific or OS specific.

 

[Arf]

I am always running in release and capturing logs with the bridgelogger, by the way.

 

[Arf]

I've disabled all handling of the received data, and put a log into AStreams_NewData to log the timestamp and number of bytes only. So this compares how often the NewData event happens and how much data for each event, between Pixel and Nexus 7.
Pixel on left, Nexus on Right:

The packets my unit is sending are 6 bytes in length, so it looks to me for some reason the bluetooth module in the Pixel is just not optimised for receiving small packets and my effective throughput is around a 20th of what it is on the Nexus.

 

[agraham]

That still looks really strange to me. In a simple world from those figures on average if you get 6 bytes every 10mS on the Nexus I would expect 120 bytes every 200mS on the Pixel. From the above it looks like you are losing a colossal amount of data - which I don't really believe is happening. Have you got some flow control getting in the way?

 

[Arf]

I have RTS/CTS flow control. All the data is coming through, it's just taking much longer. The data is basically flow data from a single exhaled breath of duration approx 4 seconds, so in the case of the nexus I would receive that data over 4 seconds and my graph look realtime, or with the Pixel the graph draws little by litte and it takes 10 seconds or whatever to draw the 4 secs worth of graph.