Re: [codec] Suggested summary...

stephen botzko <> Fri, 02 July 2010 18:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B778E3A6813 for <>; Fri, 2 Jul 2010 11:43:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q8Lz7i1Pxf0W for <>; Fri, 2 Jul 2010 11:43:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E44363A67F9 for <>; Fri, 2 Jul 2010 11:43:12 -0700 (PDT)
Received: by gxk28 with SMTP id 28so720036gxk.31 for <>; Fri, 02 Jul 2010 11:43:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=qMepDeGlb7dg7AJj6QrxdLZYo6uVCL44/7b/POHmRGM=; b=rF3RMjjDAAduMmctf4proNFsqItyMeDEbGq9Gm+5udz65jwtWpQ64bOBo5WViAx6Ii qM7fdp23DzlzluP9fh9pARo3yP8hkHvGYINUjZUyVWm3qqtMG4yyxbX7fpRK940gheEJ UgmxiJ/YmDTm7zLk7b4qifewSsxS5QFO2IYfQ=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GJSTaqgOZt1c95HzW2n+sfFy3iYEgE+zwfEjY00QG6KQdTVr3WmZKE2qH9hPo64UKd gPiK7mVnzCF9uB9oO5QtwxQ8f2NhlncxKXwYBrQgFSvoGEGUgB7vGIgzhVFjUmDFnJdY 2R6oGDLiKWSxgXQvZlw5zC3yaUuO0KHLgAhdY=
MIME-Version: 1.0
Received: by with SMTP id h7mr1867176agh.112.1278096202087; Fri, 02 Jul 2010 11:43:22 -0700 (PDT)
Received: by with HTTP; Fri, 2 Jul 2010 11:43:21 -0700 (PDT)
In-Reply-To: <000a01cb1a03$07efa100$17cee300$@de>
References: <> <> <> <> <> <000001cae173$dba012f0$92e038d0$@de> <> <001101cae177$e8aa6780$b9ff3680$@de> <> <002d01cae188$a330b2c0$e9921840$@de> <> <> <> <> <> <> <> <> <> <> <002901cafd89$acf402e0$06dc08a0$@de> <> <000601cafd9b$148fd850$3daf88f0$@de> <> <002501cafdb4$09394810$1babd830$@de> <> <001901cb19ce$a074d600$e15e8200$@de> <> <> <003a01cb19e4$ccdb8ed0$6692ac70$@de> <> <000a01cb1a03$07efa100$17cee300$@de>
Date: Fri, 02 Jul 2010 14:43:21 -0400
Message-ID: <>
From: stephen botzko <>
To: Christian Hoene <>
Content-Type: multipart/alternative; boundary="0014853c975e1d7c20048a6bf616"
Subject: Re: [codec] Suggested summary...
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 Jul 2010 18:43:15 -0000

Hi Christian

You are not mandating a 256 sample multiple on frame size, you are proposing
it as a maximum for the low delay mode.  So smaller "strange" frame sizes
are still allowed, and re-framing might be needed for some receivers.
Locking the frame size to a specific sound card's quirks does not make sense
to me, esp. since there are lots of sound cards out there, and they
certainly will have different quirks.

I agree that musical telepresence is fun to talk about, and would be fun to
build and use.  That is different from saying it is an essential application
for CODEC to work on.  In my opinion it is not. The delay bound alone limits
its use severely over the wide-area internet.  There is room for other
opinions, but I'd like to register mine.

Stephen Botzko

2010/7/2 Christian Hoene <>

>  Hi Stephen,
> *From:* stephen botzko []
> *Sent:* Friday, July 02, 2010 3:26 PM
> *To:* Christian Hoene
> *Cc:* Herve Taddei;
> *Subject:* Re: [codec] Suggested summary...
> I understand the 256 sample size (I did the math also!), though it is
> perfectly straightforward to adapt transforms to other sizes.  G.719 for
> instance uses a 960 sample DCT transform for 20 ms frame size.  There are
> many other examples that could be named.  I don't think the sound card
> argument is all that relevant, since that is a normal place to put a buffer
> anyway, and there is no reason why that buffer needs to be related to the
> frame size.
> *[Christian Hoene] If it comes to ultra low delay, the buffering at the
> sound card becomes important and must be optimized. Some sound cards (and
> their DMA controller) have restrictions on the size of blocks (called
> periods in ALSA). Having “strange” frame sizes will increase the latency
> because of re-framing.*
> Perhaps more importantly, I do not think it is appropriate to work
> backwards from technology contributions to create the requirements.
> *[Christian Hoene] You are right. However, the requirements have to be
> realistic. Looking at existing technologies helps you to know what is
> possible at the moment.*
> The normal way in the IETF is to work forward from use cases and problem
> statements.  IMHO working forward is much more likely to get good results,
> and it is fair to all (past and future) contributors.
> BTW, personally I do not place a very high priority on distributed internet
> music ensemble performances.  While I am ok if that happens to fall out of
> the design, it possibly has a lot of other implications beyond delay.  I
> would happily trade outstanding packet loss performance for music ensembles
> if it came down to it, and I suspect many other VOIP folks would concur.  Is
> there a more compelling  (maybe less fun) use case you can reference in the
> low-delay requirement?
> **
> *[Christian Hoene] Musical telepresence is a good use case because it is
> the upper limit of quality. A monaural audio transmissions can hardly be
> better. It is also a good marketing argument: The IWAC codec provides the
> best audio quality at lowest latency.  Also, this use-case is unique because
>  here is not no other standardized audio codec out here supporting it.*
> *Please have a look on the following PhD to understand the requirements of
> musical telepresence better:
> *Christian*