Telit LE910C4-EU USB audio voice latency around 480 ms

Raspberry Pi Base HATs 3G/4G&LTE Base HAT
, ,
1

Hardware:

  • Module: Telit LE910C4-EU (firmware 25.21.670 [Mar 04 2021])

  • Raspberry Pi model: Tested on Raspberry Pi and also on another Linux computer directly connected to the Sixfab/Telit module

  • Connection method: USB

  • Power supply:

    Two setups were tested:

    1. Raspberry Pi setup:

    The Sixfab/Telit module is connected through an externally powered USB hub. The USB hub has its own power supply, so the modem is not powered only from the Raspberry Pi USB port.

    1. Linux computer setup:

    The Sixfab/Telit module is connected directly to the Linux computer over USB and powered from the computer’s USB port.

    In both setups, the module enumerates correctly, registers on the network, answers GSM calls, and exposes the USB audio device.

System:

  • OS & version:

For Raspberry: Raspberry Pi OS Bookworm 64-bit

Computer: Linux Mint 22.3, Kernel:

  • Kernel version:

For Raspberry: 6.12.75+rpt-rpi-2712

Computer: 6.17.0-22-generic

SIM & Connectivity:

  • SIM card type: Lifecell
  • APN configured: Not relevant for this voice/audio test
  • Connection protocol: QMI is detected for data, but the issue is with USB audio voice path

Modem Recognition Check:

  • lsusb output:

1bc7:1230 Telit Wireless Solutions LE910C4-EU

  • dmesg | grep ttyUSB output:

    option 2-1.2:1.0: GSM modem (1-port) converter detected

    usb 2-1.2: GSM modem (1-port) converter now attached to ttyUSB0

    option 2-1.2:1.6: GSM modem (1-port) converter detected

    usb 2-1.2: GSM modem (1-port) converter now attached to ttyUSB1

    option 2-1.2:1.7: GSM modem (1-port) converter detected

    usb 2-1.2: GSM modem (1-port) converter now attached to ttyUSB2

    option 2-1.2:1.8: GSM modem (1-port) converter detected

    usb 2-1.2: GSM modem (1-port) converter now attached to ttyUSB3

    option 2-1.2:1.9: GSM modem (1-port) converter detected

    usb 2-1.2: GSM modem (1-port) converter now attached to ttyUSB4

LED Status:

  • PWR LED (red): on
  • SGNL LED (blue): blinking

AT Command Outputs:

  • AT+CREG? result: +CREG: 0,1
  • AT+CPIN? result: READY
  • AT+CSQ result: +CSQ: 25,4

Issue:
I am trying to use the Sixfab Raspberry Pi 4G/LTE Modem Kit with the Telit LE910C4-EU module as a GSM voice gateway. The module is connected over USB and appears as a USB audio device on Linux. Voice USB audio is configured with:

AT#USBCFG=11

AT#ADSPC=6,0

Linux sees the audio device as ALSA hw:1,0. The required audio format is mono, 16-bit, 16 kHz PCM.

To isolate the latency, I removed my application completely and tested only a direct ALSA loopback during an active GSM call.

I answered the incoming call with AT/ATA and then ran:

arecord -D hw:1,0 -f S16_LE -r 16000 -c 1 --period-time=5000 --buffer-time=10000 -t raw | \ aplay -D hw:1,0 -f S16_LE -r 16000 -c 1 --period-time=5000 --buffer-time=10000 -t raw

When I speak into the phone, Linux receives the audio from the Telit USB capture device and immediately sends it back to the Telit USB playback device. The returned echo delay is consistently around 0.45-0.48 seconds.

Because this test uses only direct ALSA loopback with a 10 ms buffer and no application/gateway code, I am trying to understand whether this latency is expected for the LE910C4-EU USB audio voice path, or whether I configured something incorrectly.

Full error output:
No application error. The direct loopback works, but the round-trip audio delay is around 0.45-0.48 seconds.

Relevant AT outputs:

AT#USBCFG?

#USBCFG: 11

AT#ADSPC?

#ADSPC: 6,0

AT#DVI?

#DVI: 1,2,1

AT#CAP?

#CAP: 0

AT#SRP?

#SRP: 0

What you have already tried:
* Tested my full gateway bridge and noticed voice delay.

* Removed the gateway application and tested direct ALSA loopback only.

* Tested on Raspberry Pi during an active GSM call: delay around 0.45-0.48 seconds.

* Tested on another Linux computer with the Sixfab/Telit module connected directly: same delay around 0.45-0.48 seconds.

* Confirmed USB audio routing with AT#ADSPC=6,0.

* Confirmed GSM-side voice reaches Linux capture only after setting AT#ADSPC=6,0.

* Swapped/check antennas and confirmed the modem is registered and has usable signal.

* Tried low ALSA buffer settings: --period-time=5000 --buffer-time=10000.

Since the ALSA buffer is only 10 ms and no gateway/application code is involved, it looks like the delay may be in the Telit USB audio voice path or modem voice processing.

Questions:

1. Is around 480 ms round-trip latency expected for LE910C4-EU USB audio voice?

2. Is USB audio intended for real-time voice gateway use?

3. Are there any AT commands or firmware settings that can reduce this latency?

4. Could this indicate that I configured something incorrectly?

Any guidance would be appreciated.

3

Hi @hoffman, thank you for the detailed report, your testing makes the situation very clear.

Sixfab Base HAT has no audio codec, so voice calls through the HAT are muted by design. The USB audio you tested is coming entirely from the Telit LE910C4-EU module itself, not the HAT.

Your configuration (AT#USBCFG=11 + AT#ADSPC=6,0) is correct and hw:1,0 is the Telit module’s own USB audio interface.

On the ~450–480 ms latency: this is expected behavior, not a misconfiguration. The delay is driven by the modem’s internal voice processing pipeline — GSM codec framing, Telit DSP buffering and USB isochronous transfer overhead. Even at 10 ms ALSA buffers, the modem side dominates. There are no AT commands that meaningfully reduce this.

To your questions directly:

  1. Yes, ~480 ms round-trip is expected for this USB audio path.
  2. USB audio works for basic voice use but is not well-suited for low-latency real-time gateways.
  3. No documented AT commands reduce USB audio pipeline latency significantly.
  4. Your setup is correctly configured.

If low latency is a hard requirement, the practical options are to handle audio through a separate low-latency codec and use the module only for call control (AT commands).

Let us know if you have further questions!

4

Hi @Imran, thanks for the clear explanation. That matches what I measured on my side.

Could you please clarify the practical low-latency options a bit more? When you say “handle audio through a separate low-latency codec and use the module only for call control,” do you mean an external hardware audio codec connected to the Telit module’s PCM/DVI or analog voice-call audio pins, rather than changing the cellular voice codec/vocoder inside the Telit firmware? If yes:

- Does the LE910C4-EU mPCIe module expose a usable PCM/DVI or analog voice-call audio interface?

- Does the Sixfab Base HAT expose any of those audio pins, or is USB Audio the only practical voice path with this kit?

- Is there any Sixfab board/carrier setup that supports lower-latency voice audio with this Telit module?

- Are there known modem/module alternatives that you recommend for low-latency voice gateway use?

- Is the ~480 ms delay specific to Telit USB Audio, or should I expect similar latency from most cellular modules with USB Audio voice support?

My use case is a real-time GSM voice gateway. SMS/call control works fine via AT commands, but the voice delay is the blocking issue. I’m trying to understand whether there is a realistic hardware path forward, or whether this modem/HAT combination is simply not suitable for that requirement.

5

Hi @hoffman,

Yes, that is correct. By “separate low-latency codec” we mean using a hardware audio path such as the module’s PCM/DVI or analog voice interface, if available and exposed by the carrier board. This is different from changing the cellular voice codec/vocoder inside the Telit firmware.

For the LE910C4-EU and Sixfab Base HAT setup:

  • The Telit module may support hardware voice interfaces such as PCM/DVI at the module level, depending on the exact variant and hardware design.
  • However, the Sixfab Base HAT does not expose a practical low-latency PCM/DVI or analog voice audio interface.
  • With this kit, the practical voice path is the Telit USB Audio interface.
  • We do not currently have a Sixfab carrier board that exposes a lower-latency voice audio path for this Telit module.

So, for a real-time GSM voice gateway, this modem/HAT combination is not the best fit if low voice latency is a hard requirement.

The ~480 ms delay appears to be related to the modem’s USB Audio voice path and internal buffering. This kind of delay is common with cellular modules using USB Audio for voice, so it is not simply an ALSA buffer or Raspberry Pi configuration issue.

For a lower-latency design, the recommended path would be to use a module and carrier board combination that explicitly exposes a hardware voice interface, such as PCM/DVI/I²S or analog audio and connect that to an external audio codec or audio subsystem designed for low-latency voice handling.

6

Hi @Imran ,

Thank you for your help! It helped a lot! The situation is much clearer now.