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

From: [email-masked]
Date: Thu, 9 Sep 2004 16:20:34 -0700

Hi Hari,
 
Yes, both narrowband and wideband operation of VMR-WB under cdma2000 Service Option 62 have been specified by 3GPP2 C.S0052-0 v1.0 (see Section 2 of this specification).
 
Narrowband processing has been one of the mandatory requirements of the cdma2000 wideband speech codec (see 3GPP2 S.R0080 v1.0 for more details).
 
Furthermore, VMR-WB has been proposed as wideband and narrowband multimode codec for 3GPP2 multimedia streaming and messaging applications.
 
Moreover, the use of narrowband processing in conjunction with narrowband processing is optional. You may opt not to use narrowband processing of VMR-WB, but it does not mean that this feature should not be specified in the RFC.
 
I believe using one RTP timestamp of 16000 Hz and the new optional MIME parameter would resolve all of the confusions.
 
Regards
 
-Sassan Ahmadi

-----Original Message-----
From: ext Harinath Garudadri [mailto:[email-masked]]
Sent: Thursday, September 09, 2004 3:46 PM
To: Ahmadi Sassan (Nokia-TP/SanDiego); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>: sampling rate

At 02:21 PM 9/9/2004, [email-masked] 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
[email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Sat, 11 Sep 2004 13:03:48 +0100

On 10 Sep 2004, at 00:20, [email-masked] wrote:

> Hi Hari,
>  
> Yes, both narrowband and wideband operation of VMR-WB under cdma2000 
> Service Option 62 have been specified by 3GPP2 C.S0052-0 v1.0 (see 
> Section 2 of this specification).
>  
> Narrowband processing has been one of the mandatory requirements of 
> the cdma2000 wideband speech codec (see 3GPP2 S.R0080 v1.0 for more 
> details).
>  
> Furthermore, VMR-WB has been proposed as wideband and narrowband 
> multimode codec for 3GPP2 multimedia streaming and messaging 
> applications.
>  
> Moreover, the use of narrowband processing in conjunction with 
> narrowband processing is optional. You may opt not to use narrowband 
> processing of VMR-WB, but it does not mean that this feature should 
> not be specified in the RFC.
>  
> I believe using one RTP timestamp of 16000 Hz and the new optional 
> MIME parameter would resolve all of the confusions.

No. Not only would it not resolve these confusions, it would conflict 
with normal RTP usage and all other payload formats.

Colin