在BeagleBone Black运行Gstreamer音频组播RTP时遇音频不连续错误

Hey there, let's tackle that annoying "Unexpected discontinuity in audio" error you're hitting with your GStreamer multicast setup on the BeagleBone Black. I’ve run into similar audio sync issues with embedded devices before, so let’s break down the most likely fixes step by step.

Common Causes & Solutions #

1. Fix Time Stamp Inconsistencies with audiorate #

When reading from a local file with filesrc, the stream’s time stamps can be irregular (since file reading speed isn’t tied to real-time audio playback). This throws off the RTP payloader, leading to discontinuity warnings.

Add the audiorate element to normalize the audio stream’s time stamps and sample rate before sending it to rtpL16pay:

gst-launch-1.0 -v filesrc location="test.wav" ! decodebin ! audioconvert ! audiorate ! rtpL16pay ! queue ! udpsink host=224.0.0.10 auto-multicast=true port=5555 --gst-debug-level=3

audiorate acts as a "time stamp cleaner"—it ensures the RTP payloader receives a smooth, consistently timed stream.

2. Tune the queue Element for Network Stability #

The default queue might not have enough buffer to handle sudden spikes in file reading or network latency, causing gaps in the stream. Increase the queue’s buffer size to smooth out output:

gst-launch-1.0 -v filesrc location="test.wav" ! decodebin ! audioconvert ! audiorate ! rtpL16pay ! queue max-size-buffers=100 max-size-time=1000000000 ! udpsink host=224.0.0.10 auto-multicast=true port=5555 --gst-debug-level=3

The max-size-time=1000000000 sets a 1-second buffer, which helps absorb minor delays without introducing too much latency.

3. Fix Receiving End Jitter (Even If You Didn’t Share It!) #

Discontinuity often shows up on the receiver side due to network multicast jitter. Make sure your receiving pipeline includes an rtpjitterbuffer to smooth out variable latency:

gst-launch-1.0 -v udpsrc port=5555 multicast-group=224.0.0.10 auto-multicast=true ! application/x-rtp,media=audio,clock-rate=44100,encoding-name=L16 ! rtpjitterbuffer latency=200 ! rtpL16depay ! audioconvert ! autoaudiosink

• Adjust clock-rate to match your WAV file’s sample rate (e.g., 48000 if your audio is 48kHz).
• The latency=200 sets a 200ms buffer—tweak this based on your network’s stability (higher latency = smoother playback, more delay).

4. BeagleBone Black Resource Tuning #

The BBB has limited CPU/RAM, so background processes or low priority can cause audio processing to stutter:

• Boost GStreamer’s priority: Run the command with nice to give it more CPU time:

  nice -n -10 gst-launch-1.0 -v filesrc location="test.wav" ! decodebin ! audioconvert ! audiorate ! rtpL16pay ! queue max-size-buffers=100 max-size-time=1000000000 ! udpsink host=224.0.0.10 auto-multicast=true port=5555 --gst-debug-level=3
  

• Close unused processes: Use top to check for resource-hungry apps and kill them with kill <PID>.
• Check ALSA conflicts: Ensure no other apps (like pulseaudio) are using the audio device—run fuser -v /dev/snd/* to check.

5. Verify Your WAV File isn’t Corrupted #

Sometimes the issue is with the source file itself. Test with a known-good WAV file, or use sox to re-encode your file to fix any internal frame discontinuities:

sox test.wav test_clean.wav

Then use test_clean.wav in your GStreamer command.

Quick Troubleshooting Flow #

1. Add audiorate to the sender pipeline first—this fixes most time-stamp related issues.
2. Tune the queue buffer if you still see warnings.
3. Check the receiver’s rtpjitterbuffer configuration.
4. Rule out system resource constraints on the BBB.
5. Verify the source WAV file is intact.

内容的提问来源于stack exchange，提问作者Ludovic