You are right. But in the case of AMR which is a codec to be used on not-very-reliable channels there's more than just the jitter/packet-loss every packet transporting AMR encoded audio (almost always) carries three different streams a high-quality/high-bandwidth (12.2 kbps) one, a medium one (7.40) and a poor-one (4.75) in case reception is not good it will switch to a lower bandwidth codec.
The difference between the various "speeds" is radical (although not that sensible in case of speech) in the case of musical instruments specially, the lowest bandwidth codecs convert triangular waveforms into sinusoidal ones converting a violin into something that hears more like a flute. Note: Those three bandwidths are just an example see 3GPP TS26.103 if interested in various allowed combinations currently used in 3gpp based mobile networks. Luis On Nov 30, 2007 8:08 PM, Jaap Keuter <[EMAIL PROTECTED]> wrote: > Hi, > > Isn't this a problem for every audio stream. The RTP player has a > configurable jitter buffer, but the actual endpoint usually has a > dynamic one. Also packet loss concealment can improve the perception at > the endpoint considerably. > So the RTP player is nice, but isn't really relevant for the end user > perception. > > Thanx, > Jaap > > > Luis EG Ontanon wrote: > > Just note: > > Most AMR codec/decoders take all three streams and choose the best one > > they can use but what you would hear as a middleman might not be what > > someone in the other side of a radio link is hearing. That is if we > > feed a codec in the middle we probably feed them good frames and it > > will use the higher quality stream codec (usu 14.4kbps) but the actual > > receiver might be using another lower quality stream (hearing flutes > > when listening to violins) because the radio link does not provide > > enough bandwidth for the high quality one. > > > > That means listening to the AMR that passes through a Iu/Nb link would > > be useful for snooping a conversation but non useful for diagnostic > > purposes as you might not hear the same audio the other folk gets. > > > > On Nov 30, 2007 4:43 PM, Anders Broman <[EMAIL PROTECTED]> wrote: > >> > >> Hi, > >> AMR is a licensed codec so it can't be provided with Wireshark but a plugin > >> interface exists to add your own codecs you'll have to do it yourself > >> though. > >> See also some other recent posts with AMR in the subject line. > >> Regards > >> Anders > >> > >> ________________________________ > >> > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of Sanghee Lee > >> Sent: den 30 november 2007 01:47 > >> > >> To: wireshark-dev@wireshark.org > >> Subject: [Wireshark-dev] How to playback the AMR in RTP packet > >> > >> > >> Hi, > >> > >> I know "VOIP calls" in Wireshark for playing the RTP packet. > >> > >> But, the VOIP calls only can play the G.711. I'd like to play the AMR > >> payload. > >> > >> > >> > >> Thanks in advance, > >> > >> Leo > > _______________________________________________ > Wireshark-dev mailing list > Wireshark-dev@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev > -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
