Intermittent Popping / Crackling Noise with Magpie Multilingual TTS on Jetson AGX Thor

Robotics & Edge Computing Jetson Systems Jetson Thor
,
1

Please provide the following information when requesting support.

Hardware - GPU: NVIDIA Jetson AGX Thor
Hardware - CPU: NVIDIA Jetson AGX Thor (aarch64)
Operating System: Ubuntu 24.04.2 LTS
L4T Version: 38.2.0
NVIDIA Driver Version: 580.00
CUDA Version: 13.0
Riva Version: 2.24.0
Riva Container: nvcr.io/nvidia/riva/riva-speech:2.24.0-l4t-aarch64
TLT Version (if relevant): N/A

TTS Model:
magpie_tts_ensemble-Magpie-Multilingual

Language:
en-US

Speaker ID:
0

Audio Encoding:
LINEAR_PCM

How to reproduce the issue?

We are running NVIDIA Riva 2.24.0 on an NVIDIA Jetson AGX Thor system provided by Advantech.

We are using the Magpie Multilingual TTS model for English (en-US) speech synthesis.

TTS synthesis generally works correctly. However, we intermittently hear a noticeable popping/crackling noise in the generated speech.

An important characteristic of this issue is that the popping noise usually occurs near the beginning or the end of an individual TTS audio segment.

However, there is no consistent pattern:

  • It may occur at the beginning of a TTS segment.
  • It may occur at the end of a TTS segment.
  • Some TTS segments do not contain the noise at all.
  • Repeated synthesis does not produce the noise at a predictable position or frequency.

Therefore, the issue appears to be intermittent and non-deterministic.

When the issue occurs, Riva does not report an inference error. The TTS request still completes successfully and returns OK.

A typical Riva TTS log looks like this:

TTSService.Synthesize called.
Using multispeaker model magpie_tts_ensemble-Magpie-Multilingual for inference with speaker_id: 0
TTSService.Synthesize response contains 98304 audio samples.
TTSService.Synthesize returning OK

We would like to know:

  1. Is this intermittent popping/crackling noise at the beginning or end of synthesized audio a known issue with Magpie Multilingual TTS?

  2. Are there any known issues with audio boundaries (start/end of synthesized segments) when running Magpie Multilingual TTS on Jetson AGX Thor?

  3. Are there any recommended TTS parameters, padding settings, audio settings, or model configurations that could prevent this issue?

  4. What is the recommended method to determine whether the artifact originates from the raw audio generated by Riva TTS or from the subsequent audio processing/playback pipeline?

  5. Are there any known compatibility issues between Riva 2.24.0, Magpie Multilingual TTS, and Jetson AGX Thor?

  6. Is there a newer Riva version, Magpie TTS model, or patch recommended for this configuration?

We can provide audio samples containing the issue and additional Riva server logs if required.

4

You’re posting in the DRIVE Thor forum which is for DRIVE platform.
Moving your issue to Jetson Thor forum.

5

https://docs.nvidia.com/deeplearning/riva/user-guide/docs/overview.html

There is a newer container.

ngc registry image list  nvcr.io/nvidia/riva/riva-speech
| Tag                             | Updated Date | Image Size | Signed? |
+---------------------------------+--------------+------------+---------+
| 2.26.0-l4t-aarch64              | Jun 16, 2026 | 10.37 GB   | True    |
| 2.24.0-l4t-aarch64              | Dec 16, 2025 | 10.64 GB   | True    |
7

Hi,

Thanks for reporting this.

We are not aware of the issue you mentioned. Riva 2.24 has Thor support.
Could you share the detailed command to generate the noisy speech so we can check it further?

Thanks

9

Hi,

Thank you for the reply.

We are testing Riva TTS on an NVIDIA Jetson AGX Thor with Riva 2.24.0 and the Magpie Multilingual TTS model.

Our use case is to generate several short English TTS segments and play them in sequence.

The issue is intermittent and non-deterministic.

A short popping/crackling noise may occur near the beginning or near the end of an individual synthesized segment. The noise does not occur in every segment, and repeated synthesis of the same text does not reproduce it at a fixed position or with a predictable frequency.

Riva always returns OK and does not report an inference error when the noise occurs.

One sentence where we have noticed the issue is:

Do you want to proceed with deep diagnosis?

We repeatedly synthesize this sentence using:

  • Language: en-US
  • Speaker ID: 0
  • Audio encoding: LINEAR_PCM
  • Sample rate: 22050 Hz

Our application sends the text to Riva, receives the raw PCM audio, and writes it as a WAV file.

After receiving the Riva audio, our application applies the following boundary smoothing:

  • 5 ms fade-in at the beginning of the speech
  • 20 ms fade-out at the end of the speech
  • 150 ms silence added before the speech
  • 500 ms silence added after the speech

We use this processing to avoid clicks between short TTS segments. However, we still intermittently hear popping/crackling near the beginning or end of some generated segments.

Could you please advise whether this is a known issue with Magpie Multilingual TTS on Jetson AGX Thor, and whether there are recommended settings or diagnostics for this case?

We can provide generated WAV files and Riva logs if needed.

Thanks.

11

Hi,

Sorry for the late update.
Yes, sharing the WAV and logs will help us to check the issue.

Thanks.

12

test.zip (85.0 KB)Hi,

Thanks for the update.

I have attached a ZIP file containing a WAV sample that reproduces the issue.

The abnormal popping/crackling noise can be heard at the end of the audio file.

Please let me know if you need any additional samples, specific Riva logs, or other diagnostic information to help investigate the issue.

Thanks.

13

riva_tts_issue_20260930T160700CST.log (91.4 KB)Hi,

I have also attached the Riva server log for further investigation.

The WAV sample I shared previously was generated on September 22. The attached log contains the Riva TTS activity from that day.

As mentioned earlier, the TTS request completes successfully and Riva does not report an inference error when the abnormal popping/crackling noise occurs.

Please let me know if you need any additional information or a more specific log capture.

Thanks.

14

Hi,

Thanks for sharing the data.
We have passed it to our internal team and will keep you updated.

Have you tried the container with another JetPack version, ex r39 branch?
If yes, do you also observe the same behavior?

Thanks.

16

Hi,

Thanks for the update.

We have not tested the container with another JetPack version, such as the r39 branch.

Our Thor system is currently being used as an active development platform, and our application services have already been deployed and configured on the current environment. Therefore, changing or reinstalling the JetPack version solely for this TTS test would be difficult for us at this stage.

If possible, could you please suggest any additional debugging steps or tests that we can perform on our current JetPack environment to help isolate the issue?

We would be happy to provide additional logs, audio samples, or system information if needed.

Thanks.

17

Here is something I used for another related issue that might be a work-around.

TTS pops may be amplitude discontinuities at the boundaries
between streaming audio chunks, not clicks inside them. Try to fix at the boundary and remove the artifact without touching voice quality.

File Purpose When to use
fade_per_chunk.py Applies a short raised-cosine fade-in/fade-out to every chunk. First thing to try. Simplest, near-zero CPU.
crossfade_stream.py Overlap-add equal-power crossfade between adjacent chunks. If fade_per_chunk.py leaves an audible amplitude notch at joins.
adeclip_file.sh Offline ffmpeg chain (highpass → adeclip → limiter). Escalation when pops are inside chunks, not at joins.

Python library package use:

from fade_per_chunk import Softener
s = Softener(sample_rate=22050, fade_ms=5)
for resp in riva_tts.synthesize_online(req):
    sink.write(s.soften(resp.audio))

from crossfade_stream import Crossfader
xf = Crossfader(sample_rate=22050, xfade_ms=10)
for resp in riva_tts.synthesize_online(req):
    sink.write(xf.push(resp.audio))
sink.write(xf.flush())          # emit held tail at end of stream

Keep any outer envelope (fade-in / fade-out / silence padding) on the final concatenated buffer do not apply it per chunk.

To simulate streaming on a WAV file, for A/B testing.

./fade_per_chunk.py    audio.wav audio_faded.wav
./crossfade_stream.py  audio.wav audio_xfaded.wav
./adeclip_file.sh      audio.wav audio_declipped.wav

Input WAVs must be mono int16 PCM. chunk_samples defaults to 4096 and controls how the file is re-sliced to imitate a streaming source.

Tuning parameters
fade_per_chunk.py Softener(sample_rate, fade_ms)

Param Default Effect
sample_rate 22050 Must match TTS output rate.
fade_ms 5 Fade length at each chunk edge. Longer = better hiding of discontinuities but more audible amplitude dip. 3 ms is the useful range.

crossfade_stream.py ΓÇö Crossfader(sample_rate, xfade_ms)

Param Default Effect
sample_rate 22050 Must match TTS output rate.
xfade_ms 10 Overlap window between consecutive chunks. Longer = smoother joins, more latency (one chunk-tail is held before emission). 5 ms is typical.

Latency: exactly one crossfade window (~10 ms at default). Imperceptible for TTS playback.

adeclip_file.shffmpeg filter chain

Filter chain: highpass=f=40, adeclip=w=55:o=75:a=2:t=10, alimiter=limit=0.95:attack=1:release=5

Filter Param Default here Meaning
highpass f 40 Hz Removes DC offset and subsonic thumps that read as low-frequency pops.
adeclip w 55 Window size in ms.
adeclip o 75 Overlap percentage. Higher = smoother, more CPU.
adeclip a 2 Attack in ms.
adeclip t 10 Detection threshold. Raise if it over-detects clean speech.
alimiter limit 0.95 Peak ceiling (full-scale). Catches residual spikes.
alimiter attack 1 ms How quickly the limiter engages.
alimiter release 5 ms How quickly it releases.

If Option A/B eliminates the pops then the source was possibly chunk-boundary discontinuity.

If pops remain after Option B then they are inside chunks. Run adeclip_file.sh on the concatenated output.

adeclip_file.sh.txt (412 Bytes)
crossfade_stream.py.txt (2.6 KB)
fade_per_chunk.py.txt (1.9 KB)

18

Thanks for the suggestion. I checked our implementation again and would like to clarify how our current TTS pipeline works.

In our sentence-playback client, the input text is first split into individual sentences. Each sentence is then sent to our TTS service as a separate request.

For example:

Text
→ split into Sentence 1 / Sentence 2 / Sentence 3
→ Sentence 1 → one TTS service request → one Riva TTS request → one WAV file
→ Sentence 2 → one TTS service request → one Riva TTS request → one WAV file
→ Sentence 3 → one TTS service request → one Riva TTS request → one WAV file

For each request, our TTS service uses:

self.service.synthesize(…)

rather than the streaming API. The Riva server log also identifies these requests as:

riva.tts.synthesizeoffline.v1

For each request, Riva completes synthesis and returns the full PCM audio in a single response.audio. On the client side, we do not receive, buffer, or concatenate multiple Riva streaming audio chunks.

The returned PCM is written directly to a mono, 16-bit, 22.05 kHz WAV file. After the complete WAV is created, we apply fade-in/fade-out processing and add silence padding at the beginning and end of the file.

In the sentence-playback client, the resulting sentence WAV files are then played sequentially in their original order.

Therefore, although the input text may be split into sentences by the client, each sentence is independently synthesized as one complete offline Riva response and stored as one WAV file. There are no Riva streaming chunk boundaries being concatenated on the client side in our current implementation.

For this reason, the proposed per-chunk fade/crossfade approach does not appear to directly apply to our current offline synthesis path.

19

Hi,

We are still discussing this issue with our internal team.
Will update with more information with you later.

Thanks.

20

Hi,

Could you try with the newer 2.26.0 release?
There are some fixes included to improve the end of speech and quality.

Thanks.

21

Hi,

Please give v2.26.2 a try.
Using the same command below, we can reproduce the pop noise at the end of the segment:

# python3 /opt/riva/examples/talk.py \
  --text "Hello from AGX Thor." \
  --voice "Magpie-Multilingual.EN-US.Aria" \
  --language-code en-US \
  --sample-rate-hz 22050 \
  --encoding LINEAR_PCM \
  --output /opt/riva/wav/output.wav

But the issue is solved with the v2.26.0 RIVA container.

Thanks.

22

Hi,

Thanks for the update. I’ll give RIVA v2.26.2 a try and see if it resolves the issue on my side.

Thanks!