V1.12.8 - Save payload .au file does not show problem as heard in Player of RTP Stream Analysis

The reason is that while the RTP player imitates the behaviour of a real gateway device by simulating use of a de-jittering buffer, which is something all gateway devices have to use, the Save Payload As... doesn't do this.

So the difference you describe indicates that you wanted to use Save Payload As... to document some issue with garbled sound, assuming that the source of the RTP or of the audio contents itself was faulty, but that the real cause of the garbled sound is actually a network issue.

The travel time of any packet through the network from the source to the destination is not the same for all packets. These deviations of travel time of individual packets from the mean travel time of all packets in the same stream are called "jitter". Due to its existence, it would be a bad idea to start playing the contents of any received RTP packet immediately as it comes, because if it would take the next one longer to get to you, you'd have finished playing the contents of the first packet and have nothing to play until the next one would arrive, causing a garbled sound at the output. To prevent this, gateways intentionally do not start playing packets immediately after reception of the very first one, but first build a queue of several packets. The longer the queue, the better tolerance to delayed packets, but the worse the user experience, so different developers use different strategies and even adjust the queue sizes dynamically.

The queue size is also an issue. At multi-channel gateways,

• you cannot give an unlimited amount of memory to each channel,

• the playback sample rate is usually common for all streams.

So if the source of the packets uses a slightly faster sample rate than its recipient, the playback queue grows with time, and if its size is limited, you have to drop those incoming packets which come while there is no space in the queue (or better use some smoothing techniques, dropping individual samples rather than whole packets), resulting in audio quality deterioration.

So when you encounter a garbled sound issue, but Save Payload As... saves a clean sound and Wireshark statistics shows no lost packets in the stream (i.e. the RTP sequence numbers of the packets in the stream are monotonously rising by one), look at the times elapsed between packet arrivals. If they differ heavily (in fact, any jitter values of tens of milliseconds, i.e. comparable to the packetization time, need attention) already at the point of capture, it means that you have to have a look to the dejittering buffer parameters at the receiving gateway. If you cannot see any interesting jitter values (jitter lower than packetization time usually doesn't make any real life trouble), but Wireshark tells you that the sample rate differs from the expected one (which is 8000 Hz for most traditional audio codecs but it is not a law of physics), it may also be that the jitter buffer underruns (new packets arrive too slowly due to lower sampling rate at the sending side) or overruns (new packets arrive too fast).

In the RTP player, you can imitate the de-jittering buffer behaviour of a particular gateway, if you know that gateway's settings, by setting the size of dejittering buffer in the RTP player window. Or you can switch the dejittering buffer simulation off by setting Playback Timing to Uninterrupted mode (i.e. same behaviour like Save Payload As...) if you want to check "by ear" whether jitter or something else is the cause of the issue. You can also set Playback Timing to Use RTP Timestamps (roughly, playing the packets as they looked at the sender), which more or less can only reveal sender's issues with timestamping.

More sophisticated dejittering buffer strategies are not implemented in the RTP player (yet?).