Re: [codec] #8: Sample rates?

stephen botzko <stephen.botzko@gmail.com> Tue, 13 April 2010 13:21 UTC

Return-Path: <stephen.botzko@gmail.com>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF9A3A69A1 for <codec@core3.amsl.com>; Tue, 13 Apr 2010 06:21:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67ua1gvKTbhv for <codec@core3.amsl.com>; Tue, 13 Apr 2010 06:20:56 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 1C1883A692D for <codec@ietf.org>; Tue, 13 Apr 2010 06:20:50 -0700 (PDT)
Received: by pwj2 with SMTP id 2so5357140pwj.31 for <codec@ietf.org>; Tue, 13 Apr 2010 06:20:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=BMOXQYGh/SrCZUFWIv5OVUlVHQ68jQ5c1EEXkbTbd2I=; b=STbzKnO+pwZdrDjVOMfVhQJLiqrQfoB+dsh0caCDBXSRYK2Zn+WOSkvlaKo2DSSgrB qj5NqJS46c5tWXtfGwGxQLkgFRgLbZNAzLocUXWhXhQe4LuzBZaLsU9TGrakfbtVWBSu iNfDZb4dCMxYKwJnY9wO/gnBznGFzukLePiFU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NBldxS30k/N7TC5BSERCohZpQwzWtnZZMovx/LeEbtfUFsFO+kbXy6yGfy4j4VAogk 6Q4T5aIIg1Hod3CYlkGR3E2QnqDzVADxglJeBPIkzgDZbNcg6NOoJESGU0+pMMmggtbr Jj+ey7WICp+0i+wNk8UUGTg8thnKUxI7K1jN8=
MIME-Version: 1.0
Received: by 10.231.85.133 with HTTP; Tue, 13 Apr 2010 06:20:42 -0700 (PDT)
In-Reply-To: <4BC4586F.1010709@digium.com>
References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <071.0bc6655c98ff0335ad26ee705d9f5ce9@tools.ietf.org> <002a01cadac8$68dbf380$3a93da80$@de> <w2k6e9223711004130337l5ecfccdbl153ac4895aedfdf@mail.gmail.com> <4BC4586F.1010709@digium.com>
Date: Tue, 13 Apr 2010 09:20:42 -0400
Received: by 10.141.187.12 with SMTP id o12mr5350655rvp.43.1271164842811; Tue, 13 Apr 2010 06:20:42 -0700 (PDT)
Message-ID: <o2u6e9223711004130620lb04d335auaafacfa34b0d6fe7@mail.gmail.com>
From: stephen botzko <stephen.botzko@gmail.com>
To: "Kevin P. Fleming" <kpfleming@digium.com>
Content-Type: multipart/alternative; boundary="000e0cd18222e8236104841e202c"
Cc: codec@ietf.org
Subject: Re: [codec] #8: Sample rates?
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Apr 2010 13:21:00 -0000

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 <kpfleming@digium.com>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: kfleming@digium.com
> Check us out at www.digium.com & www.asterisk.org
>