Re: [codec] requirements #8 (new): Sample rates?

Koen Vos <koen.vos@skype.net> Wed, 26 January 2011 05:56 UTC

Return-Path: <koen.vos@skype.net>
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 996E23A692E for <codec@core3.amsl.com>; Tue, 25 Jan 2011 21:56:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.279
X-Spam-Level:
X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6]
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 Yqpkh6aOSimd for <codec@core3.amsl.com>; Tue, 25 Jan 2011 21:56:38 -0800 (PST)
Received: from mx.skype.net (mx.skype.net [78.141.177.88]) by core3.amsl.com (Postfix) with ESMTP id 45EE23A6843 for <codec@ietf.org>; Tue, 25 Jan 2011 21:56:37 -0800 (PST)
Received: from mx.skype.net (localhost [127.0.0.1]) by mx.skype.net (Postfix) with ESMTP id 8F28016FC; Wed, 26 Jan 2011 06:59:36 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=date:from:to :cc:message-id:in-reply-to:subject:mime-version:content-type; s= mx; bh=lFVj/xzP5+3mLIm9+4BFl5SGSgo=; b=XycALisTspV6lZ6/6WxtSDX2U Wl9OfcMZA/qVRAqxACvuBNWA195pyClFBJFBFlt3PZY5GMTMEKcRpwogkcALFcdB 4NUJvQfz7/JppZD7fmTEoatF7kF/Q2ZFpzOSovCVt/oS2qEFQyCL+0rFhzdy+SDy Y/Qc5TDQV+6NetgUpw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=date:from:to:cc :message-id:in-reply-to:subject:mime-version:content-type; q=dns ; s=mx; b=llkSm35VBh3z7uPqfj2eHXysyrCb1XGiBP59wBSzM978TwratY3qNU Ey2j+HkzmXKif0Fea3pB02toQyT2S2oT0VY9TO5DNEsnxUE3gfYd7rQoveVsunaL m8DZjzOGVkVPJtcgKvT5HEKZmyj3APJW2AaYIapINWQtiXRiq9Oik=
Received: from zimbra.skype.net (zimbra.skype.net [78.141.177.82]) by mx.skype.net (Postfix) with ESMTP id 8D53F7F6; Wed, 26 Jan 2011 06:59:36 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by zimbra.skype.net (Postfix) with ESMTP id 7422B35074FF; Wed, 26 Jan 2011 06:59:36 +0100 (CET)
X-Virus-Scanned: amavisd-new at lu2-zimbra.skype.net
Received: from zimbra.skype.net ([127.0.0.1]) by localhost (zimbra.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NzOCBQ0awkQ; Wed, 26 Jan 2011 06:59:23 +0100 (CET)
Received: from zimbra.skype.net (lu2-zimbra.skype.net [78.141.177.82]) by zimbra.skype.net (Postfix) with ESMTP id 4D1673507487; Wed, 26 Jan 2011 06:59:23 +0100 (CET)
Date: Wed, 26 Jan 2011 06:59:23 +0100
From: Koen Vos <koen.vos@skype.net>
To: "Raymond (Juin-Hwey) Chen" <rchen@broadcom.com>
Message-ID: <1108895421.1374993.1296021563190.JavaMail.root@lu2-zimbra>
In-Reply-To: <CB68DF4CFBEF4942881AD37AE1A7E8C75F44516D66@IRVEXCHCCR01.corp.ad.broadcom.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_1374992_461071571.1296021563187"
X-Originating-IP: [69.181.192.115]
X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - FF3.0 (Win)/6.0.9_GA_2686)
Cc: codec@ietf.org
Subject: Re: [codec] requirements #8 (new): 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: Wed, 26 Jan 2011 05:56:40 -0000

Hi Raymond, 

Streaming of CD music was not an anticipated use case or requirement. That said, 44.1 kHz support at the API is certainly nice to have. 

My understanding of how CELT works is that a *native* 44.1 kHz mode with a power-of-2 frame size would break the flexibility to seamlessly switch API sampling rates or coded audio bandwidth on the fly. (Jean-Marc can shine more light on this.) This feature makes it easy for applications to switch during a call between sources or streams that have different sampling rates. 

I'm also not as negative about resampling as you are: modern hybrid-FIR/IIR designs are very efficient, and I'm convinced a 44.1<->48 kHz resampler with transparent quality can be built with 10~20 MACs per sample. And resampling happens everywhere anyway: most hardware ADCs and DACs resample internally, and even Opus internally resamples in many of its modes already. 

So if desired we could support 44.1 kHz at the API level, without losing the nice flexibility properties we've so painstakingly built into the design. (Agree we have to think about how to handle 2.5 and 5 ms frames at 44.1 kHz, but I'm sure we'll find a solution.) 

best, 
koen. 


----- Original Message -----
From: "Raymond (Juin-Hwey) Chen" <rchen@broadcom.com> 
To: codec@ietf.org 
Cc: "jean-marc valin" <jean-marc.valin@usherbrooke.ca> 
Sent: Tuesday, January 25, 2011 4:53:38 PM 
Subject: Re: [codec] requirements #8 (new): Sample rates? 




I agree that supporting sampling rates of 48, 16, and 8 kHz all makes sense, but I also think it would be highly desirable to support 

another common sampling rate used by music CDs: 44.1 kHz. 



For music streaming applications, a large percentage of the music sources will have this 44.1 kHz sampling rate. I know it is 

possible to up-sample them to 48 kHz first and then pass them through the 48 kHz version of Opus. However, doing such up- 

sampling requires additional processing power and additional latency, and if the sampling rate conversion is not done with a 

high-quality method (which usually requires higher complexity and higher delay), audio quality degradation may be introduced 

in the process. For these reasons, many people prefer not to do the 44.1 kHz to 48 kHz sampling rate conversion and prefer to 

encode the 44.1 kHz music directly instead. Therefore, it is highly desirable for Opus to support this 44.1 kHz sampling rate. 



I understand that it may be inconvenient for the SILK mode or the SILK+CELT hybrid mode to support 44.1 kHz. However, for the 

CELT-only mode, my understanding is that the current CELT C code already supports the 44.1 kHz sampling rate. Since the CELT- 

only mode is also the most suitable mode to encode music, it would then make perfect sense for the CELT-only mode to also 

support this 44.1 kHz in addition to 48 kHz. 



Furthermore, currently the CELT mode at 48 kHz supports frame sizes of 2.5, 5., 10, and 20 ms to be consistent with the frame 

sizes of the SILK mode and SILK+CELT hybrid mode, and this results in frame sizes and FFT window sizes that are not powers of 2, 

which reduces the implementation efficiency. If the CELT mode supports the 44.1 kHz sampling rate, then since it is no longer 

possible to support exactly 2.5, 5, 10, and 20 ms at this sampling rate anyway, I think we might as well choose the FFT window 

sizes to be powers of 2 to allow more efficient implementation. Again, such power of 2 FFT sizes at 44.1 kHz is already supported 

in the current C code for CELT, so no new development is needed. 



In summary, I propose that we allow the CELT-only mode of the Opus codec to officially support the 44.1 kHz sampling rate using 

power of 2 FFT window sizes to avoid sampling rate conversion and to allow the most efficient implementation. 



Raymond 




From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Roman Shpount 
Sent: Monday, January 24, 2011 5:08 PM 
To: codec@ietf.org 
Cc: jean-marc.valin@usherbrooke.ca 
Subject: Re: [codec] requirements #8 (new): Sample rates? 



I actually do believe that the requirement is already addressed by section 4.1 of the document. I was responding to a comment that only full band is required, which is clearly not what we agreed upon and not what's in the document. 
_____________ 
Roman Shpount 




On Mon, Jan 24, 2011 at 7:40 PM, codec issue tracker < trac@tools.ietf.org > wrote: 


#8: Sample rates? 


Comment(by gmaxwell@…): 


On 11-01-24 07:14 PM, Roman Shpount wrote: 
> I would like to see 8 and 16 KHz as required rates for the codec to 
insure 
> interoperability with existing narrowband and wideband codecs. In other 
> words we should be able to negotiate 8 or 16 Khz sample rate if audio 
will 
> be transcoded for PSTN or wideband codec such as G.722 


Jean-Marc wrote: 
> I believe such requirement for narrowband/wideband is already present, 
but 
> I don't mind making it even more explicit is necessary. 




I believe that we since are close enough to finalizing the draft we should 
try to include proposed language with our issues. Otherwise there may be 
no clear path forward. 

Some of the requirements specify that compatibility with 
wideband/narrowband is important, but for the avoidance of doubt, I'll 
suggest: 

At the end of 4.1. Operating space: 

"Because interoperation with existing wideband and narrowband facilities 
is essential at least one method of interoperation must be provided 
regardless of the codec's operating mode, sample rate, or bitrate." 

Of course, I would be perfectly happy to leave this out entirely (as I 
believe the application section 2.1 already implies the requirement) or 
use some other language. 

-- 


------------------------------------+--------------------------------------- 
Reporter: hoene@… | Owner: jean-marc.valin@… 
Type: enhancement | Status: new 
Priority: minor | Milestone: 
Component: requirements | Version: 
Severity: Active WG Document | Keywords: 
------------------------------------+--------------------------------------- 

Ticket URL: < http://trac.tools.ietf.org/wg/codec/trac/ticket/8#comment:4 > 


codec < http://tools.ietf.org/codec/ > 

_______________________________________________ 
codec mailing list 
codec@ietf.org 



https://www.ietf.org/mailman/listinfo/codec 


_______________________________________________ 
codec mailing list 
codec@ietf.org 
https://www.ietf.org/mailman/listinfo/codec