RE: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>: sampling rate

Harinath Garudadri <hgarudad@qualcomm.com> Fri, 10 September 2004 08:08 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02123 for <avt-archive@ietf.org>; Fri, 10 Sep 2004 04:08:48 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5gWi-0000Pz-Fq for avt-archive@ietf.org; Fri, 10 Sep 2004 04:13:00 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5gP5-0002YS-JN; Fri, 10 Sep 2004 04:05:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C5Xgv-0006gO-29 for avt@megatron.ietf.org; Thu, 09 Sep 2004 18:46:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12497 for <avt@ietf.org>; Thu, 9 Sep 2004 18:46:53 -0400 (EDT)
Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C5Xkr-0007Zs-64 for avt@ietf.org; Thu, 09 Sep 2004 18:51:01 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i89MkI1i004396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Sep 2004 15:46:19 -0700 (PDT)
Received: from HGARUDAD.qualcomm.com (hgarudad.qualcomm.com [129.46.75.112]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i89MkDWY013240 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 9 Sep 2004 15:46:13 -0700 (PDT)
Message-Id: <6.0.0.20.2.20040909152932.02c68918@m3.qualcomm.com>
X-Sender: hgarudad@m3.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.20 (Beta)
Date: Thu, 09 Sep 2004 15:46:11 -0700
To: sassan.ahmadi@nokia.com, magnus.westerlund@ericsson.com
From: Harinath Garudadri <hgarudad@qualcomm.com>
Subject: RE: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>: sampling rate
In-Reply-To: <0B08EA1BF5F6304992CDC985EE02209E02A74362@sdebe002.americas .nokia.com>
References: <0B08EA1BF5F6304992CDC985EE02209E02A74362@sdebe002.americas.nokia.com>
Mime-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1
X-Mailman-Approved-At: Fri, 10 Sep 2004 04:04:24 -0400
Cc: Qiaobing.Xie@motorola.com, csp@csperkins.org, avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0277767263=="
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3

At 02:21 PM 9/9/2004, sassan.ahmadi@nokia.com wrote:
>Hi Magnus,
>
>Please find my response to your comments below:
>
> > Based on what you write in the previous mail. It seems that the only
> > reason for using different RTP timestamp rate between 8000
> > and 16000 Hz
> > is to indicate the sampling rate of the source material.
>
>This is correct. The only reason that I defined two RTP clock rates was to 
>differentiate between narrowband and wideband media in the encoder and the 
>decoder.
>
>If your original media is narrowband, since the decoder does not care 
>about the input sampling frequency, you generate a wideband output, unless 
>somehow the decoder is informed. I initially thought that this could be 
>achieved by the RTP clock rate.

Hi Sassan,
I am quite confused by the narrowband operation of VMR-WB. Based on the 
discussions here and in 3GPP2, it is not clear how the D/A convertor and 
other circuitry will handle analog output to the speaker at 16 kHz or 8 kHz 
appropriately. I believe this applies to both streaming and storage of 
VMR-WB data.

Can you tell us if 3GPP2 recommends usage of VMR-WB in narrowband mode? 
Either for circuit switched operation of packet switched services? It is 
not clear from the references in the 3GPP2 IETF dependency list if 
narrowband operation of VMR-WB codec is a requirement.

If narrowband operation of VMR-WB is not a requirement, it will be lot 
cleaner to restrict this draft to wideband only. This would address 
concerns raised by Magnus, Qiaobing and others. Thanks,

hari.

> > If the codec
> > does not need any indication at all if the source material is
> > 8k or 16k
> > then, I think the usage of different RTP timestamp rates is creating
> > unnecessary interoperability barriers. The barrier is that
> > one actually
> > needs to indicate the rate of the source material, and cope with RTP
> > timestamp switching.
>
>Agreed.
>
>
> > To avoid the unnecessary function I would propose that VMR-WB only
> > defines 16kHz as RTP timestamp rate. If there is desire to have
> > knowledge about source sampling rate that will be used, then
> > one should
> > define a parameter that indicates that. But I am not certain
> > it really
> > is needed. Such a parameter is declarative and does not matter in
> > regards to any interoperability and can be ignored without
> > consequence.
> > Or is it something else about the codec that prevents this? I
> > would not
> > think so as the file format can be fine without an explicit
> > indication
> > of the source sampling rate.
>
>This is a good suggestion. We need to define the RTP timestamp as 16000 Hz 
>to maintain compatibility with RFC 3267 and the AMR-WB interoperable mode. 
>But it is still important to have a declarative MIME parameter 
>"sampling-frequency" for the RTP payload to inform the encoder and decoder 
>when a narrowband media is processed. That parameter is going to be 
>optional and if not present that output of the decoder will be wideband 
>regardless of the input sampling frequency.
>
>Now if someone injects some narrowband tones or announcements, that does 
>not affect the RTP timestamp and does not affect the decoding.
>
>If you agree, I make the following changes to the VMR-WB I-D:
>
>1- Only one RTP timestamp clock rate of 16000 Hz is used throughout the I-D.
>2- A new optional MIME parameter "sampling-frequency" is defined with the 
>following description:
>
>sampling-frequency:    The input/output media sampling frequency. 
>Permissible values are 8000 (narrowband) or 16000 (wideband, default). If 
>16000 or not present, indicates that the input/output media sampling 
>frequency is 16000 Hz.
>
>The reason that I used the term media is that the input to the encoder or 
>the decoder output could be speech, audio (e.g., music, tone, etc.).
>
>If this is acceptable, I will make the necessary changes in the I-D and 
>submit a new draft shortly.
>
>Regards
>
>-Sassan Ahmadi
>
>
>
>_______________________________________________
>Audio/Video Transport Working Group
>avt@ietf.org
>https://www1.ietf.org/mailman/listinfo/avt

Dr. Hari Garudadri
Qualcomm Inc.
work    : 858-651-6383
mobile : 858-229-2801
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt