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

Erel

B4X founder

Staff member

Licensed User

Longtime User

• Sep 13, 2020

• #2

Are you using AsyncStreams in prefix mode?

Does it behave differently if the device is charged?

 

Upvote 0

Arf

Well-Known Member

Licensed User

Longtime User

• Sep 13, 2020

• #3

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

 

Upvote 0

Erel

B4X founder

Staff member

Licensed User

Longtime User

• Sep 14, 2020

• #4

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

 

Upvote 0

agraham

Expert

Licensed User

Longtime User

• Sep 14, 2020

• #5

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

 

Upvote 0

Erel

B4X founder

Staff member

Licensed User

Longtime User

• Sep 14, 2020

• #6

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

 

Upvote 0

Arf

Well-Known Member

Licensed User

Longtime User

• Sep 14, 2020

• #7

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:

B4X:

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:

 

Upvote 0

Erel

B4X founder

Staff member

Licensed User

Longtime User

• Sep 14, 2020

• #8

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.

 

Upvote 0

agraham

Expert

Licensed User

Longtime User

• Sep 14, 2020

• #9

Arf said:

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

Click to expand...

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?

 

Upvote 0

Arf

Well-Known Member

Licensed User

Longtime User

• Sep 14, 2020

• #10

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.

 

Upvote 0

Arf

Well-Known Member

Licensed User

Longtime User

• Sep 14, 2020

• #11

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

 

Upvote 0

Arf

Well-Known Member

Licensed User

Longtime User

• Sep 14, 2020

• #12

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.

 

Upvote 0

agraham

Expert

Licensed User

Longtime User

• Sep 14, 2020

• #13

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?

 

Upvote 0

Arf

Well-Known Member

Licensed User

Longtime User

• Sep 14, 2020

• #14

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.

 

Upvote 0