Sideband LXST Voice Calls For Android

[markqvist]

I have just uploaded a preview release of Sideband for Android that includes a full audio backend implementation for LXST on Android. The audio implementation uses the native Android audio APIs, allowing direct audio input and output streaming and the ability to use low-latency pipelines.

This all means that you can now have live, full-duplex voice calls on Android, to and from any other LXST telephony endpoints, such as Sideband on desktop, rnphone and physical LXST telephones.

The audio backend I wrote for this allows you to select and use any audio devices available on the device as inputs and outputs. Out of the ~32 different audio device classes available in Android, I've only tested it with the obvious and normal stuff such as the built-in devices, bluetooth headsets, etc. Be my guest and try it out with the more esoteric device classes such as TYPE_FM_TUNER, TYPE_BLE_BROADCAST, TYPE_MULTICHANNEL_GROUP or TYPE_DOCK_ANALOG; sure to be interesting, but I have no clue what behavior to expect ;)

On that note, it seems there is actually an audio device class called TYPE_TELEPHONY, which would allow Sideband to route normal GSM/LTE calls over LXST/Reticulum. I have currently disabled this, though, as it seems it requires special permissions and may only be accessible to system apps or on rooted devices. This is probably a very niche feature, but it could be interesting to explore using this as a bridge between LXST calls and the "old world".

Either way, this is a preview release, and will most likely be a little rough around the edges. Some caveats to be aware of:

• Make sure that you have given Sideband microphone permission to use this. I'm pretty sure I didn't add a mic permission check yet when activating voice calls.
• To use voice features, you have to enable them first in Preferences -> Enable voice calls.
• You can optionally enable a low-latency output path, that will significantly improve call latency on Android. This is currently a bit experimental, and I have no clue which Android versions this actually works well on yet. Some of the API stuff I'm using here is a bit opaque. This is a best-effort approach at making it work correctly across Android versions, but if it does not let me know how it fails and what version you're on!
• I'd highly recommend configuring your output and input device options in the voice config section (Voice -> Settings icon at the top).

[simplyequipped]

Only basic testing so far, but this is generally working for me on two Samsung Galaxy S24's running Android 16. Pretty excited about this!

[markqvist]

Awesome to hear! I'm pretty stoked about it too :)

[r8io]

This is awesome stuff! But I am not having any luck so far. No audio device shows up in the voice configuration.

Sideband log

OSError: Could not determine default audio output device, no suitable device available

System Information
Google Pixel 6a
GrapheneOS (Android 16, up to date)
Sideband 1.8.1 Preview

[r8io]

I installed the lastest build 1.8.1-pre dce43bd and gave it a try. Still no audio device found.

The full log file is attached to this reply. Here are some important events:

sideband_log_1.8.1-pre_dce43bd

line 829:
11-08 07:56:06.156  4806  4826 V pythonutil: Loading library: python3.11

line 1012:
11-08 07:56:03.967  4737  4790 I python  : [ERROR  ] code for hash blake2b was not found.

line 2151:
11-08 07:56:07.747  4806  4826 I sidebandservice: [ERROR  ] code for hash blake2b was not found.

line 2226:
11-08 07:56:39.563  4737  4790 I python  : [2025-11-08 08:56:39] [Error]    Failed to find default devices. Available devices on this system are: 
[
{'id': 21, 'name': 'Pixel 6a', 'type': 15, 'type_description': 'Internal Microphone', 'channel_counts': [1, 2], 'is_source': True, 'is_sink': False, 'is_comms': False, 'is_virtual': False}, 
{'id': 22, 'name': 'Pixel 6a', 'type': 15, 'type_description': 'Internal Microphone', 'channel_counts': [1, 2], 'is_source': True, 'is_sink': False, 'is_comms': False, 'is_virtual': False}, 
{'id': 30, 'name': 'Pixel 6a', 'type': 28, 'type_description': 'Unrecognized', 'channel_counts': [2], 'is_source': True, 'is_sink': False, 'is_comms': False, 'is_virtual': False}
]
11-08 07:56:39.564  4737  4790 I python  : [2025-11-08 08:56:39] [Error]    An unhandled <class 'OSError'> exception occurred: Could not determine default audio output device, no suitable device available
11-08 07:56:39.564  4737  4790 I python  : [2025-11-08 08:56:39] [Error]    Traceback (most recent call last):
11-08 07:56:39.564  4737  4790 I python  :   File "/home/markqvist/Information/Source/Sideband/sbapp/.buildozer/android/platform/build-arm64-v8a/build/python-installs/sideband/arm64-v8a/kivy/base.py", line 339, in mainloop
11-08 07:56:39.564  4737  4790 I python  :   File "/home/markqvist/Information/Source/Sideband/sbapp/.buildozer/android/platform/build-arm64-v8a/build/python-installs/sideband/arm64-v8a/kivy/base.py", line 383, in idle
11-08 07:56:39.564  4737  4790 I python  :   File "/home/markqvist/Information/Source/Sideband/sbapp/.buildozer/android/platform/build-arm64-v8a/build/python-installs/sideband/arm64-v8a/kivy/base.py", line 334, in dispatch_input
11-08 07:56:39.564  4737  4790 I python  :   File "/home/markqvist/Information/Source/Sideband/sbapp/.buildozer/android/platform/build-arm64-v8a/build/python-installs/sideband/arm64-v8a/kivy/base.py", line 302, in post_dispatch_input
11-08 07:56:39.564  4737  4790 I python  :   File "kivy/_event.pyx", line 731, in kivy._event.EventDispatcher.dispatch
11-08 07:56:39.564  4737  4790 I python  :   File "/home/markqvist/Information/Source/Sideband/sbapp/.buildozer/android/app/kivymd/uix/button/button.py", line 1145, in on_touch_up
11-08 07:56:39.564  4737  4790 I python  :   File "/home/markqvist/Information/Source/Sideband/sbapp/.buildozer/android/app/kivymd/uix/behaviors/ripple_behavior.py", line 404, in on_touch_up
11-08 07:56:39.564  4737  4790 I python  :   File "/home/markqvist/Information/Source/Sideband/sbapp/.buildozer/android/platform/build-arm64-v8a/build/python-installs/sideband/arm64-v8a/kivy/uix/behaviors/button.py", line 179, in on_touch_up
11-08 07:56:39.564  4737  4790 I python  :   File "kivy/_event.pyx", line 727, in kivy._event.EventDispatcher.dispatch
11-08 07:56:39.564  4737  4790 I python  :   File "kivy/_event.pyx", line 1307, in kivy._event.EventObservers.dispatch
11-08 07:56:39.564  4737  4790 I python  :   File "kivy/_event.pyx", line 1231, in kivy._event.EventObservers._dispatch
11-08 07:56:39.564  4737  4790 I python  :   File "<string>", line 16, in <lambda>
11-08 07:56:39.564  4737  4790 I python  :   File "/home/markqvist/Information/Source/Sideband/sbapp/.buildozer/android/app/ui/voice.py", line 188, in settings_action
11-08 07:56:39.564  4737  4790 I python  :   File "/home/markqvist/Information/Source/Sideband/sbapp/.buildozer/android/app/ui/voice.py", line 209, in update_settings_screen
11-08 07:56:39.564  4737  4790 I python  :   File "/home/markqvist/Information/Source/Sideband/sbapp/.buildozer/android/app/ui/voice.py", line 193, in update_devices
11-08 07:56:39.564  4737  4790 I python  :   File "/home/markqvist/Information/Source/Sideband/sbapp/.buildozer/android/app/LXST/Sources.py", line 44, in __init__
11-08 07:56:39.564  4737  4790 I python  :   File "/home/markqvist/Information/Source/Sideband/sbapp/.buildozer/android/app/LXST/Platforms/android/soundcard.py", line 282, in default_microphone
11-08 07:56:39.564  4737  4790 I python  :   File "/home/markqvist/Information/Source/Sideband/sbapp/.buildozer/android/app/LXST/Platforms/android/soundcard.py", line 258, in server_info
11-08 07:56:39.564  4737  4790 I python  : OSError: Could not determine default audio output device, no suitable device available

sideband_log_1.8.1-pre_dce43bd .txt

[markqvist]

Okay, so it's not actually finding any output devices at all, which looked weird at first, but I just realized I probably missed something from the Android audio API docs: "an empty [channel counts] array indicates that the device supports arbitrary channel counts."

I've now added handling for this case, and uploaded a new build. Let me know if it works!

[r8io]

Hurray, the audio devices show up now and I was able to call the rnphone utility on my computer.

The audio was not so clear. It sounded scrambled. Both with and without the Low-latency output enabled. I will play around with the settings and see if can improve things.

As always, thank you so much for making this cool stuff happen!

[r8io]

Okay, now it works! The scrambled audio problem was actually a audio feedback problem, as I should have realized in the first place. When I use headphones on my computer and get somebody to talk to me on the phone from another room things just work fine. Time to get some proper headsets.

[markqvist]

Allright! That is amazing to hear! Very nice :)

Yes, the feedback thing will be an issue for now. Some devices have built-in echo cancellation in the audio pipelines, some don't.

LXST will have its own echo-cancellation built in down the road, along with other relevant processing components such as noise reduction and voice filtering, but I haven't gotten to implementing those yet (lots of DSP math stuff I need to remember), so hopefully headphones (or using the "Earpiece" device) can make do for now.

[enema-combatant]

Woot!!

…

On Fri, Nov 7, 2025, 5:40 PM markqvist ***@***.***> wrote: Hang tight, update incoming... — Reply to this email directly, view it on GitHub <#978 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALE3POBB7S3ENN3CT7VRCLT33UNW3AVCNFSM6AAAAACLNVYRGOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIOJQG42DKNY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[markqvist]

Aight, the pre-release build has been updated. It now uses a list of fallback device types for the default sinks/sources if standard ones aren't available.

[enema-combatant]

Amazing direction. I'm assuming sinks from the Android side are 'audio endpoints' in the system? Would a Bluetooth headset be such a sink? Further, could push to talk work - e.g. using a headphone with the multitude of buttons, one usually is the prime button for 'action'. Curious but none the less appreciative. Hope to test this weekend.

…

On Fri, Nov 7, 2025, 6:20 PM markqvist ***@***.***> wrote: Aight, the pre-release build has been updated <https://github.com/markqvist/Sideband/releases/tag/1.8.1-pre>. It now uses a list of fallback device types for the default sinks/sources if standard ones aren't available. — Reply to this email directly, view it on GitHub <#978 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALE3POHCRSIF6PIZMYZ7W6T33USMNAVCNFSM6AAAAACLNVYRGOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIOJQG43DMOI> . You are receiving this because you commented.Message ID: ***@***.***>

[markqvist]

Yes, sinks are audio endpoints that can be written to (like speakers or line outs), sources ones that can be read from (like microphones or line ins).

And yes, bluetooth headsets are supported, works just fine. Tested this with a couple of old headsets I had laying around, and a pair of more recent noise-cancelling headphones as well.

Here's all of the weird and wonderful endpoint types I discovered:

TYPE_AUX_LINE: "Aux Line", # 0x13 - API level 23
TYPE_BLUETOOTH_A2DP: "Bluetooth A2DP", # 0x08 - API level 23
TYPE_BLUETOOTH_SCO: "Bluetooth SCO", # 0x07 - API level 23
TYPE_BUILTIN_EARPIECE: "Internal Earpiece", # 0x01 - API level 23
TYPE_BUILTIN_MIC: "Internal Microphone", # 0x0f - API level 23
TYPE_BUILTIN_SPEAKER: "Internal Speaker", # 0x02 - API level 23
TYPE_DOCK: "Dock", # 0x0d - API level 23
TYPE_FM: "FM", # 0x0e - API level 23
TYPE_FM_TUNER: "FM Tuner", # 0x10 - API level 23
TYPE_HDMI: "HDMI", # 0x09 - API level 23
TYPE_HDMI_ARC: "HDMI ARC", # 0x0a - API level 23
TYPE_IP: "IP", # 0x14 - API level 23
TYPE_LINE_ANALOG: "Analog Line", # 0x05 - API level 23
TYPE_LINE_DIGITAL: "Digital Line", # 0x06 - API level 23
TYPE_TELEPHONY: "Telephony", # 0x12 - API level 23
TYPE_TV_TUNER: "TV Tuner", # 0x11 - API level 23
TYPE_UNKNOWN: "Unknown", # 0x00 - API level 23
TYPE_USB_ACCESSORY: "USB Accessory", # 0x0c - API level 23
TYPE_USB_DEVICE: "USB Device", # 0x0b - API level 23
TYPE_WIRED_HEADPHONES: "Wired Headphones", # 0x04 - API level 23
TYPE_WIRED_HEADSET: "Wired Headset", # 0x03 - API level 23
TYPE_BUS: "Bus", # 0x15 - API level 24
TYPE_USB_HEADSET: "USB Headset" # 0x16 - API level 26
TYPE_HEARING_AID: "Hearing Aid" # 0x17 - API level 28
TYPE_BUILTIN_SPEAKER_SAFE: "Ringer Speaker" # 0x18 - API level 30
TYPE_BLE_HEADSET: "BLE Headset" # 0x1a - API level 31
TYPE_BLE_SPEAKER: "BLE Speaker" # 0x1b - API level 31
TYPE_HDMI_EARC: "HDMI EARC" # 0x1d - API level 31
TYPE_REMOTE_SUBMIX: "Remote Submix" # 0x19 - API level 31
TYPE_BLE_BROADCAST: "BLE Broadcast" # 0x1e - API level 33
TYPE_DOCK_ANALOG: "Analog Dock" # 0x1f - API level 34
TYPE_MULTICHANNEL_GROUP: "Multichannel Group" # 0x20 - API level 36

All of those should be supported for calls now, at least in some capacity. Why you would route HDMI Enhanced Return Channel audio over a call, I haven't the foggiest, but there's bound to be something fun to use it for :)

[markqvist]

Oh, and regarding PTT, I'm still looking into how to handle that. It's not really rolled into the Audio APIs themselves it seems, and it's a little confusing how to deal with it in just a semi-standardized manner, but there's bound to be a way.

[markqvist]

New build just uploaded with support for audio devices that list arbitrary channel count support.

[yuz86]

yuz86
25 minutes ago

Hello everyone, we have been waiting for this event for a long time, as it marks a turning point in the development of this project and elevates it to the status of a full-fledged messenger. I tested the audio call on two of my phones with custom firmware on Android 15, and I can say right away that there is currently no button to answer a call, which usually opens on a disabled screen to receive a call. Now you need to unlock your smartphone, go to the Voice tab in the program, and answer the call there. As I understand it, the Opus codec is currently used, which provides fairly good voice quality, but only with an internet connection of at least 3G. With a 2G connection, I was unable to talk comfortably, as the voice was constantly interrupted with huge delays and gaps in phrases. I believe that for this project, it is essential to provide the option of using low-bitrate codecs such as Codec2 or Melpe 1200. For example, when calling via Torfon, which uses the Melpe1200 codec, the voice quality is comparable to that of the standard G729 telephone codec operating at a speed of 8000 bits/sec. When calling on a 2G connection, it allows you to talk comfortably even in cases where a regular voice call starts to be interrupted by fragments of phrases and dropouts at very long distances from cell towers. I posted the source code for this program and the author's voice module here in my previous post about voice calls in Sideband. With respect to you.

[markqvist]

it is essential to provide the option of using low-bitrate codecs such as Codec2

Codec2 is already fully supported by LXST and implemented on both Android and desktop platforms. The LXST protocol even supports dynamic codec switching on the fly and mid-call. There's just no UI toggle for enabling it yet ;)

there is currently no button to answer a call

Right now, you have to answer the call from the "Voice" screen by pressing the "Answer" button, or use the Ctrl + Space shortcut (or Ctrl + . shortcut to reject).

As I said, this is a preview release, and will most likely be a little rough around the edges ;)

Hopefully, I will have time to integrate call answering with the native Android call handling UI/notifications before the real 1.8.1 release, but believe it or not, making sure that kind of stuff works consistently across the many different Android versions is one of the most time-consuming things you can imagine.

[markqvist]

The pre-release build has been updated with some more tweaks and fixes.

[markqvist]

The pre-release build has been updated with proper support for audio device mapping on Android versions 11 and lower.

[daylight-hub]

Thank you! This one fixed it for me running a Sonim XP8!! All works well.

[yuz86]

I tested the quality of voice calls in urban conditions, moving between densely built-up areas with LTE connectivity enabled. From what I can immediately note, it is already possible to make calls, but there is no automatic jitter buffer, which adds some delay, within acceptable limits, but at the same time, the voice is not broken up into pieces. This is exactly what happens now: the voice is interrupted, and during a voice call, you can really feel the uneven reception of IP packets. I haven't tested this on 2G due to the extremely low internet speed, although with the help of specialized programs such as Linphone and Torfone, you can comfortably talk on a 2G connection while on the move and even from semi-basement rooms in stores where the signal reception is minimal.
On home internet with a stable signal, Sideband sounds pretty good during voice calls.

[markqvist]

Actually, LXST already implements a fully configurable, buffered, internally mixable, completely staged and interconnectable pipelined audio architecture, where each individual point in the audio pipeline can have buffers (and other parameters) adjusted on the fly, and in real-time.

Right now, the telephony pipeline is simply tuned for low-latency throughput, which achieves that, as long as you have a relatively stable (in terms of packet jitter) connection. Currently, the maximum buffer height at the mixing stage is only 2 frames, and at the output sink it will be practically zero if you have the low-latency option enabled (on Android). In the current configuration, frame times are configured at 40ms, I believe, although LXST supports arbitrary frame times (depending on codec capabilities, of course).

You can easily do 5ms frames, which yields extremely low latency over fast connections. You can just as easily increase frame times to something like 80 or even 100ms, configure a higher buffer threshold in the receive mixer, and you'd have an incredibly stable connection regardless of packet jitter.

It's really just all down to what you prefer. For telephony, I personally prefer as low latency as entirely possible, and don't care about a few discontinuities. For other kinds of comms, I'd prefer the opposite, for example two-way radio, where I think a bit of latency is less of a concern, and continuity is more important.

The great thing is, I designed LXST so it can support any and all of these configurations and use-cases dynamically, and even adjust on the fly when conditions change.

When building things, I tend strongly towards designing an architecturally and structurally correct system where every part of the foundation is in place, before throwing "fancier" features on. The nice thing about this approach is that now that the foundation is there, all of those things are basically already implemented, in the sense that enabling them for users, making them configurable, making them automatically managed, or whatever really, is just a matter of 2-5 lines of code. Further, it can be managed on a per-primitive (or even per-application) basis. I think that is the most elegant way to handle things.

Before fiddling around with the easy and fun stuff, such as dynamic jitter buffers and on-the-fly frame-time optimizations, there's more important things on my list of priorities, specifically the DSP-related pipeline components, such as voice optimization filters and live echo-cancellation, and thereafter the remaining primitives for broadcast media and routed+direct two-way radio comms.

Thanks for all the testing and reports! Really useful and interesting to hear!

[brothercorvo]

Tested with a Poco phone 5 pro
Android 15, xiaomi os 2.0
and a Samsung S8.
Sideband Last version 1.8.1
The call works but on the Poco the microphone input is not captured. On the S8 everything works

[markqvist]

Thanks @brothercorvo!
Could you try with this new build, and if it's still not working on the Poco, can you let me know:

• What input devices are listed in the voice configuration options on the Poco?
• Turn on Debug Logging, then open the voice configuration screen, and then go into the log viewer and copy the last output for me, which should relate to audio device discovery (could be in either the frontend or the service log).

[markqvist]

Also, are both the S8 and the Poco on Android 15? Stock OS or a custom ROM?

[markqvist]

The pre-release build has been updated with:

• A call log on the voice screen
• Missed call notifications
• Going directly to the voice screen by tapping on a call-related notification
• A "Reject" button on the voice screen for rejecting incoming calls

[markqvist]

The pre-release build has been updated with:

• A fix for the voice screen not loading if voice calls were disabled. Duh.

[markqvist]

The pre-release build has been updated with:

• Much better device type detection and audio mode allocation across different Android versions
• Improved call notifications

[daylight-hub]

Will this work with Lineage OS?

[markqvist]

Yes, Sideband is written to not make use of any Google support libraries or dependencies, and only access native Android APIs directly. For custom ROMs, I'm mostly testing on GrapheneOS, since I just don't have the time to test across all kinds of devices and ROMs (already have a test suite of about 10 different devices and Android versions). So it should work just fine, but if you do find anything weird happening, let me know.

[enema-combatant]

Yes. Should

…

On Wed, Nov 12, 2025, 10:16 PM 1matichs ***@***.***> wrote: Will this work with Lineage OS? — Reply to this email directly, view it on GitHub <#978 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALE3POGPDWOTLLTUSIMUBRT34PZXPAVCNFSM6AAAAACLNVYRGOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIOJVGQZDSNQ> . You are receiving this because you commented.Message ID: ***@***.***>

[markqvist]

The preview release APK has been updated with the ability to connect RNodes over Wifi and Ethernet.

[markqvist]

The preview release APK has been updated with various stability tweaks for connecting RNodes over WiFi and Ethernet.

[markqvist]

The preview release APK has been updated with:

• The ability to select call profiles on the voice screen, including low-bandwidth options using Codec2
• Improved channel stat output for RNodes with interference detection stats
• Ability to clear call log
• Probably other tweaks and stuff I've forgotten

Check it out!

[markqvist]

Oh, yeah, I did forget: The ability to start Sideband as a background service on boot :)

[sigases]

We encountered strange behaviour or possibly a glitch in the latest version of Sideband with voice calls. In the latest version with LTE connection, there are very strong freezes and stuttering of the voice on the MQ codec. When switching to a higher quality codec, the voice becomes clearer, but the stuttering and freezes are still present. On 2G internet, we were unable to talk normally even on narrowband codecs, although before the update to version sideband-1.8.2-arm64-v8a-pre-release-4, the voice sounded much clearer. Today we reinstalled the programme to the pre-release version and the call quality has indeed improved significantly.

[markqvist]

What devices and Android versions? It sounds like this could be the phone being very old and slow enough that it cannot run the DSP filters in real-time (these were added). In all testing I have conducted here, call quality is excellent, even on slow connections.

[sigases]

I have a Xiaomi Poco F6 phone with a Snapdragon® 8s Gen 3 processor and 12/512 memory. One of our correspondents has a Xiaomi 14 Pro phone with a Snapdragon 8s Gen 3 processor and 12/256 memory. Our smartphones have custom firmware with Android 15 installed, and two other correspondents have slightly simpler smartphones, but also modern ones with Android 12 and 14. We all live in different cities at a great distance from each other, in one case between North America and Europe. We are interested in testing and comparing different versions of the program with all available codecs and cellular communication ranges from 2G (edge) to 4G (LTE). If possible, today we will conduct a series of voice communication tests between different correspondents using the previous version of the program, which we used yesterday evening with much better call quality. One of the correspondents lives in a rural area at a considerable distance from cell towers and only has access to very low-speed 2G internet.

[markqvist]

Also, please consider, that if you are running this over the public testnet/development TCP entrypoints, your data is routed over a system:

• That is running on a single-core, very slow virtualized server
• With on average over 1000 active other RNS nodes connected, most of them doing all kinds of weird stuff
• Being used for testing failure scenarios, load spikes, announce spamming, etc., etc.
• Often running experimental versions of RNS for testing stuff

If you want to have an actual idea of call quality, latency, and so on, while running over the Internet, it's probably advisable that you set up your own TCP entrypoint for your users to connect via, using the BackboneInterface interface type.

[sigases]

Hello, everyone. A new project ( https://freedv.org/radio-autoencoder ) has recently been launched for encoding voice at ultra-low bit rates using artificial intelligence, enabling voice quality comparable to that of high-quality audio codecs at a data transfer rate of only 700 bits/sec. One of the programmes where this project has been implemented is called FreeDV ( https://github.com/drowe67/freedv-gui ). I just tested this programme by connecting it with a virtual cable to my browser in Windows and launching one of the online shortwave receivers from websdr.org. I was very impressed with the voice quality on the shortwave connection, where this codec allows signals to be decoded at a level 2 dB below the noise levels of the airwaves.
Mark, please pay close attention to this development, as it will allow us to completely abandon the entire list of codecs in the Reticulum project, as they are not very effective, in favour of the Rade codec.

[markqvist]

I have indeed been following the development of RADE for some time.

it will allow us to completely abandon the entire list of codecs in the Reticulum project, as they are not very effective, in favour of the Rade codec.

This is the most silly thing I've heard in a while. Do you think embedded devices and low-end phones are able to run the ML model in real-time? Do you only want to support the frame times and channel configs that RADE supports? Do you want to abandon the ability to stream perceptually lossless signals? Do you want to not support low-latency signal paths.

I wish people would think before talking....

[markqvist]

For the record: RADE/FreeDV operates directly at the radio PHY layer. LXST operate at the application layer. While RADE is an amazing achievement (and could potentially be integrated as an option in LXST), your recommendations are meaningless. The existing codec suite is carefully chosen to support Reticulum's diverse range of hardware and use cases, from resource-constrained LoRa devices to desktop applications.

If you believe RADE is the future, the path forward is clear:

• Write a Python binding for the RADE model and codec that can run in real-time on a Raspberry Pi Zero.
• Integrate it into LXST.
• Benchmark it against Codec2 and OPUS across all supported platforms.
• Submit a pull request with your code, benchmarks, and a detailed technical justification.

The protocol is public domain. If you don't like the engineering choices, you are free to build your own version of Reticulum and LXST that uses only RADE.