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 <jaap.keuter@xxxxxxxxx> 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 <anders.broman@xxxxxxxxxxxx> 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: wireshark-dev-bounces@xxxxxxxxxxxxx
> >> [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Sanghee Lee
> >> Sent: den 30 november 2007 01:47
> >>
> >> To: wireshark-dev@xxxxxxxxxxxxx
> >> 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@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan