0

I tried to build and run the example ChirpConnectConsoleDemo in ChirpSDK-.Net-3.4.0 and found it was only able to receive the first, the third , the fifth and so on messages when I run a Chirp's message sender (running on Android device)(The Android Chirp message sender is modified based on the example chirp-android-examples to segment message by its MaxPayloadLength and send data chunk-by-chunk). In other words, the second, the fourth, the sixth and so on chunks would be lost.

I ever tried the Android example chirp-android-examples as the receiver. Using the same sender app on a Android device and running the same Android app on the other Android device as the receiver, the receiver can successfully receive all messages (no message lost).

I expected the Windows example also can successfully receive all messages sent from the Android Chirp app. However, as what I described, it always lost the even messages. Can anyone help me? Thanks.

hamer
  • 123
  • 1
  • 6

1 Answers1

1

The issue could be that you are sending payloads too quick, meaning there is no enough delay between payloads. Ideally, you should have at least 0.5 seconds of delay.

If the processing time is slow and the internal audio buffer size is small, this can quickly lead to a buffer overflow which means the SDK will miss chunks of audio.

Dinu
  • 390
  • 1
  • 2
  • 12
  • Thank Dinu. I tried to set the delay to 2 seconds and then it works. However, I'm curious why .Net library's performance is worse than Android version because the message sender app running on Android device is the same. Why Android receiver app can successfully receive all delivered message chunks, but Windows' version can not. – hamer Aug 23 '19 at 22:57
  • My original implementation was that setting 200 milliseconds delay to send the next message chunk after getting OnSent callback in the Chirp example app. In order to make Windows receiver app can receive all message chunks, I ever tried to set the delay to 500 ms and 800 ms. But it did not work as expectation until I set the delay to 2 seconds. – hamer Aug 23 '19 at 22:58
  • It's all about the combination of the audio buffer size and the decoding speed of the SDK. If the buffer size is bigger and/or the decoding is slower than the delay between payloads, the SDK will miss the first few ms of the next payload which means it will miss the whole payload. Although the decoding is usually really fast on most of the devices, the buffer size can affect the latency quite a lot. On Android SDK the buffer size is defined by the device's min buffer size, not sure about the Windows SDK, however, 2 seconds of delay is way too much. What device are you running the SDK on? – Dinu Aug 24 '19 at 12:44
  • Apologise, its opposite to what I said before, the combination of small buffer size plus slow processing makes the buffer to overflow which leads to missing audio bytes but again, 2 seconds is too much, must be something else going on there. – Dinu Aug 24 '19 at 13:12
  • Sorry for inaccurate testing. When I said I need to set 2 seconds delay to receive all message chunks, I just tried 0.2 s, 0.5 s, 0.8 s and then 2 sec delay. Today I tried to set 0.1 s as the unit to check how much delay should be set. Then I found the receiver client could not receive all chunks until it was set to 1.8 s (I test 5 rounds for each delay setting and treated it failure if there is any round failed in the 5 rounds.). – hamer Aug 26 '19 at 06:18
  • So on my laptop, Windows 10 64-bit system with intel i7-8650U/16G RAM, I need to set 1.8 seconds delay following OnSent callback to send the next message chunk for the Android message sender app. – hamer Aug 26 '19 at 06:19
  • Can you send us your sources through [support.chirp.io](https://developers.chirp.io/support) and we'll do a bit of testing to debug the issue. – Dinu Aug 26 '19 at 09:47