Errors in program operation

[Skretch1974]

After installing and testing version 3.1.5 (301051) with F-Droid on the phone with custom firmware Android 12.1 without Google services, revealed the following critical defects:

1. Inactive in the settings of the line enable / disable the auto-start program after rebooting the phone - as a result of the program itself is not running.
2. When setting the last two positions in the list of camera resolutions for video calls, the program spontaneously goes to reboot.
3. When you turn on the phone "silent" does not work the vibration alarm and there is no notification about the received message, in general, no reaction of the phone, and only manually entering the program shows that the message came.
4. . The program periodically loses connection with the server, although all the restrictions on battery and Internet traffic savings are turned off. As a result, only restarting the program restores the connection with the server and the work of the program.
5. None of the available in the set codecs when selecting the lowest bitrate did not allow to make a call in 2G Internet, while for example the SIP application Lingphone perfectly works on the Internet speed of 64 kbit / sec. codec SILK

[cmeng-git]

From the test observations provided, it appears to me that you are using a self compiled code. Some of the below comments are based on this assumption.

1. Android put a security restriction on app running on android above API-28. All android app are not allowed to start app activities from background. Due to aTalk design architecture, auto-start option will on work under this case. In aTalk source, the option has actually been disabled for android API above 28.

    private void initAutoStart() {
        if (Build.VERSION.SDK_INT > Build.VERSION_CODES.P) {
            ConfigurationUtils.setAutoStart(false);
            findPreference(P_KEY_AUTO_START).setEnabled(false);
        }
        PreferenceUtil.setCheckboxVal(mPreferenceScreen, P_KEY_AUTO_START,
                ConfigurationUtils.isAutoStartEnable());
    }

2. I have just re-tested the video call on the following devices with aTalk version 3.1.5 (301051):

a. Pixel 6 Pro API-33 (Emulator) b. Samsung Note-10 API-31 c. Samsung J730 API-28. I cannot reproduce the problem. The video calls are working fine on these 3 devices.

Please note that the video resolutions settings are derived based on device camera capabilities. Do not hard coded these values settings in the option lists.

3. In all app implementation, all notifications and alerts are required to channel through android OS. Therefore final app notifications and alerts behavior are very much depended on user app notification settings.

Please refer to aTalk online help for better understanding: [20200619] aTalk Heads-Up Notification and Quiet-Hours

4. Please refer to online help on how aTalk handle network connection:

[20180710] XEP-0198:Stream Management and ReConnection Manager](https://cmeng-git.github.io/atalk/faq.html#feature_06) [20181015] Network Keep Alive - Ping Interval Optimization

Your observations are likely due to poor network connection and fading.

5. The codec bit-rate options were never being tested during aTalk development. The options are inherited from the forked source.

Please note that aTalk supports real time media encryption, hence requires much higher resources than an unsecured video calls. You may need to use the lowest video resolution and disable all the media stream encryption before carrying out such test.

[Skretch1974]

Hi. On 1 point, the application I downloaded from the F-Droid This link, https://f-droid.org/repo/org.atalk.android_301051.apk no self-compilation, etc., did not make, as in this absolutely do not understand.

As for the second point, this error I found by accident, in the process of setting up and testing the program between two smartphones. The program was closed several times because of the critical error, until I put a smaller camera resolution. I almost do not use video calls and it is not very relevant to me.

On the 3rd point, no additional bans and restrictions on notifications in the android settings, everything is allowed. This is also not a particularly critical error and in normal mode calls and notifications come.

On the 4th point - the loss of connection was also detected on the second phone with Android 7, the program also rolled up spontaneously after some time in sleep mode and did not activate itself. For example, a similar program Conversations keeps connection for weeks in standby mode without any problems.

On the 5th point, I gave an example of the program Linphone, which also implemented encryption ZRTP and used encrypted transport protocol TLS1.3, it does not affect the quality of processing and transmission of voice traffic on low bitrate channel. This function is actually the most important part of such programs, because it is on the mobile terminal the most unpredictable mode of client programs, constant packet loss, variable Ping and sudden speed jumps in the communication channel due to the peculiarities of radio wave propagation in urban areas and on the ground.

In addition, there is the Torfone project https://github.com/gegel/torfone , where the author conducted a very deep research on the characteristics of the voice codecs in networks with low speed, the result of his work was this program, which works perfectly on GPRS channels with AES-256 encryption and key negotiation protocol on DH-4096. In his project there are unique author's codecs for work in low-speed networks with traffic masking.

You are doing a very necessary and correct project, I hope to participate a little in its testing, discussion and work. Regards.

[cmeng-git]

1: May be I have misunderstood your initial questions to arrived at this assumption.

The "Auto start aTalk on reboot' option is not available for android above API-28; android OS does not allow app from start any activity from background. This has limited aTalk to offer such option on >API-28.

2: May I know what is the manufacturer and model of your phone? Is your phone installed with standard android OS?

On my side I am just unable to reproduce this problem, even tested on android 5.0 API-21 Google Nexus 9 emulator.

3: Did I misunderstood your initial question.

When you turn on the phone "silent" does not work the vibration alarm and there is no notification about the received > message, in general, no reaction of the phone, and only manually entering the program shows that the message came.

If this just your comment. Then it is correct to mention that when you enabled android silent mode, android OS will inhibit all aTalk heads-Up, and notification including the badge count value from showing.

4: Not comment to much on conversations. There are pro and con between apps. aTalk pings the network every 240 Seconds by default. If not mistaken, conversations uses a shorter ping interval. Please enable ping and set to a lower ping interval to see if the problem is resolved. Pleases also ensure you DO NOT enable battery optimisation on aTalk.

5: As mentioned in my previous comment. The aTalk codec refined parameters were not tested; I am not sure if the set values are actually being used in codec setup. Currently aTalk has not intention to do further work on this areas; as aTalk implementation has no intention to support network with low bandwidth.

[Skretch1974]

Hi. There is a LPCNet project that has developed a voice codec with neural reconstruction of the original speech, operating at a speed of 1600 bits https://github.com/xiph/LPCNet Also one of the examples of its implementation https://github.com/drowe67/LPCNet It is unfortunate that you do not plan to develop the program as a universal means of primarily reliable voice communication specifically for mobile terminals, where there is no guaranteed quality of the speed of the provided communication channel and, of course, it is simply impossible to talk using such programs with the provided list of voice codecs. I had to drop Conversations as well, for the same reasons. Very often, when moving around, I notice how my phone switches networks from LTE to 3G and 2G, which leads to the impossibility of making voice calls at all on the provided codecs. So far, the only programs that have allowed making comfortable calls are Torfone and Linpfone. Good luck and thank you for your detailed and honest answer.

[cmeng-git]

I have retested all the aTalk codecs (audio/video) including the expect settings, they are all working under standard test environment. Note you need to restart aTalk if you change any of the expert codec settings.

Just releases aTalk v3.1.6, which include two new audio codec i.e. G722 and G729. You may want to try out these two codecs to see if they work in your environment. To ensure the appropriate codec is used in call, enable only one codec and any one time. You may enable all other codecs on the other test device. Please disable all call encryption during test, as encryption increases the bit rate during transmission.

By the way, what exactly is the observed problem when you mentioned the codec is not working: e.g. a. Call setup failed b. No audio heard on either devices c. Audio heard but chirpy. d. Error message shown on the devices if any. Take a screenshot if possible.

[Skretch1974]

Hi. I downloaded and installed the new version of Atalk on 2 of my smartphones with Android 12.1 and Android 7.

Forced the phones in the SIM card settings to "only GSM" Internet connection in EDGE mode, in the applications set the codec 729 in priority, disabled the rest and reloaded the application. Of the several attempts to call received 1 time, the phrase spoken in the microphone on two phones was heard without distortion, with a huge delay of 27 seconds on one of the phones! On the second phone the said phrase appeared after about 4-5 seconds.

To monitor also compared the application Linphone ( https://download.linphone.org/snapshots/android/ ) with the codec Speex8000 and a bitrate of 10 kilobits / sec, in the encryption mode ZRTP. The connection occurred each time without problems, the voice delay in both directions was not more than 1.5 - 2 seconds, the voice quality was noted as excellent, without distortion or breaks.

At 3G speed Atalk application already works well from stationary conditions (both smartphones were in a stationary place with good cell tower signal strength). In general, Atalk leaves a good impression, all in terms of text messaging, everything works very well, but as for the voice over networks with high packet loss and variable Jitter value, everything becomes much more complicated, in professional radio on this pay special attention, develop specialized codec Melpe, Codec2 and similar with a very low bit rate and good quality restored voice. If you have free time, pay attention to the development of Mr. Gegel https://github.com/gegel https://habr-com.translate.goog/ru/articles/448856/?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp&_x_tr_hist=true

[cmeng-git]

From your test observations, I believe the problem is more than just the network bandwidth limitations. In your aTalk tests, I see that there are major delays between the two phones and connection success rate is low, I suspect your devices resources e.g. CPU speeds etc play a major role in your observed problems. This slow processor speed may well cause problem during the initial call setup (time out) leading to a low success rate in call connection; and the long delay on received audio due to voice data processing time.

Please note majority of aTalk implementation is using java, and with the feature complexity, it requires reasonable good device to work properly. The ZRTP encryption algorithms are coded in Java and likely to have problem on slow device; unlike other codecs used in aTalk, the G729 codec is also coded in Java (from original forked source).

but as for the voice over networks with high packet loss and variable Jitter value,

The amount of actual voice data transmitted during each call session, over the network should be the exactly the same for both aTalk and Linphone. I believe this is due to your device processing time resulted from limited device resources.

By the way, you do not need to restart aTalk when selecting difference codec types. You only need to restart aTalk when you try to manipulate the codec parameters in 'Expert settings'.

[Skretch1974]

Hi. Today I once again repeated the experiment on two identical smartphones Xiaomi Poco f3 ( https://www.gsmarena.com/xiaomi_poco_f3-10758.php ) with custom firmware on Android 12.1 Both phones forcibly switched to 2G only mode and the test of voice calls was performed with 3 programs (aTalk v3.1.6, linphone-android-debug-5.1.0-beta.23+8397debb0.apk ( https://download.linphone.org/snapshots/android/ and simplex.chat ( https://simplex.chat/ )) All 3 programs were configured with each other in encryption mode. The program Linphone with Speex8000 codec and 10 kbps bitrate has the least delay and practically no discomfort, the second quality is simplex.chat, which by the way works very well with voice through the TOR network, the voice traffic delay of this program does not exceed 3-4 seconds. Atalk unfortunately impossible to talk even setting 729 codec, because of the very high latency. of several connections was only one with encryption ZRTP, in other cases, the program made a connection without encryption with a very long delay voice. When switching the phones to 3G mode, all three programs already worked very well voice calls, with minimal voice delay. Thank you for paying attention to some points in the improvement of your project. With respect to you.

[cmeng-git]

To really understand where is voice call setup limitations, please install your devices with the aTalk debug version from the link below: https://github.com/cmeng-git/atalk-android/blob/master/aTalk/release/aTalk-fdroid-debug.apk

Perform the tests to reproduce unsuccessful call connection, and call with long latency. After that send me the debug log for further investigation. Please see online help on how to send the debug log. [20200418] How can I give feedback to the developer for any aTalk problem encountered?

[cmeng-git]

The observed problems are not due to aTalk, but the operation is limited by the device resource couple with restricted network bandwidth.

Please note, comparable with linphone which has limited supported features, it is solely writeen in 'C", should not be measured against aTalk.

Issues closed due to non new activity from user.