Re: [codec] #8: Sample rates?

["Christian Hoene" <[e-mail]>]

Hi,
 
It still might make sense to negotiate the maximal supported sampling rate via SDP or, if possible, to select one out of multiple
sampling rates, if the audio receiver can cope with multiple rates well. The internal sampling frequency of the codec NEEDS NOT to
be affected by the external sampling frequency.
 
However, the decoder might want to signal to the encoder that the decoding is requiring too many computational resources and that a
less complex coding mode (or a lower sampling frequency) should be taken.
 
Christian
 
 
---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of Tübingen 
Sand 13, 72076 Tübingen, Germany, Phone [phone] 
 <http://www.net.uni-tuebingen.de/> http://www.net.uni-tuebingen.de/
 
From: stephen botzko [mailto:[e-mail]] 
Sent: Tuesday, April 13, 2010 3:21 PM
To: Kevin P. Fleming
Cc: Christian Hoene; [e-mail]
Subject: Re: [codec] #8: Sample rates?
 
Though I generally avoid MAY, this could be a case where it makes sense.

Something like:

CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to optimize audio quality.

This is free of any technology assumption about how the acoustic bandwidth is reduced.  The MAY indicates that it is permissible.
But if the CODEC algorithm doesn't need to reduce the acoustic bandwidth, then we are making no statement that it SHOULD (or SHOULD
NOT).

Kevin is distinguishing dynamic changes to the sample rate (for bandwidth management) from multiple fixed sample rates; and I agree
that is a key distinction. 

I have not heard any clear application requirement for more than one fixed sampling rate.  Though if there is such a requirement,
IMHO we would have to negotiate the rate within SDP in the usual way, and it would affect the RTP timestamps, jitter buffers, etc.
G.722.1 / G.722.1C is one precedent - it is the same core codec, but can run at two different sample rates (negotiated by SDP).

Stephen Botzko
On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming <[e-mail]> wrote:
stephen botzko wrote:

> Dynamically changing sample rates on the system level adds some
> complexity for RTP, since the timestamp granularity is supposed to be
> the sample rate.
And jitter buffers, and anything else that is based on timestamps and
sample rates/counts. If the desire is for the codec to be able to change
sample rates to adjust to network conditions, then I agree with
Stephen... the 'external' sample rate (input to the encoder and output
from the decoder) should be fixed, and this is what would be negotiated
in SDP and used for RTP timestamps. The codec can downsample in the
encoder and upsample in the decoder if it has decided to transmit fewer
bits across the network.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [e-mail]
Check us out at www.digium.com & www.asterisk.org