Subject: [codec] #8: Sample rates?

From: "codec issue tracker" <[email-masked]>
Date: Sun, 11 Apr 2010 14:53:58 -0000

#8: Sample rates?
------------------------------------+---------------------------------------
 Reporter:  hoene@…                 |       Owner:     
     Type:  enhancement             |      Status:  new
 Priority:  minor                   |   Milestone:     
Component:  requirements            |     Version:     
 Severity:  Active WG Document      |    Keywords:     
------------------------------------+---------------------------------------
 Which sample rate(s) will the proposed codec support? If more than one,
 will one of the sample rates be a MUST handled by all implementations,
 with the others optional dependent on the capabilities of the endpoint?
 Will each sample rate variation of the codec be treated as a unique codec
 as far as SDP negotiation is concerned?

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

---

From: "codec issue tracker" <[email-masked]>
Date: Mon, 12 Apr 2010 22:53:51 -0000

#8: Sample rates?

Comment(by kpfleming@…):

 If our goal is to use RTP AVP/SAVP/AVPF/SAVPF profiles for transport (as
 seems likely), then differences in sample rates between stream offers must
 be listed separately in the SDP. Whether they have a different codec
 'name' in the SDP or not seems less important, because the combination of
 the codec name and sample rate is required to uniquely identify the format
 in any case. Note that this is *sample rate*, and not bitstream rate.

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

---

From: "Christian Hoene" <[email-masked]>
Date: Tue, 13 Apr 2010 07:15:55 +0200

>#8: Sample rates?

No, please not. Please keep the interface to the codec as simple as possible!
 
In addition, one must consider the following requirements:

1) First, the sample rate MUST be changed dynamically to cope with varying transmission bandwidths.
2) Typically, sound cards do not allow changes of the sample rate on the fly. 
3) Thus, the codec SHOULD have an internal sampling rate conversion.

I would recommend to use only one nominal sampling rate (e.g. the sampling rate of the sound card) and let the codec do the conversion between the actually used and predefined.

It might be useful to state that it is not recommended to use 44100 Hz, because the conversion to 16kHz and 32kHz is computational more demanding than 48kHz and requires more power/time.

With best regards,

 Christian

---

From: stephen botzko <[email-masked]>
Date: Tue, 13 Apr 2010 06:37:47 -0400

I do not think that we should include multiple sample rates in the
requirements at all.

If you use *internal *sample rate conversion in the encoder and the decoder;
then that becomes part of the compression, and is transparent to the
system.  There are other ways to accomplish the same end - for instance
removing (not transmitting) high frequency coefficients in a transform
coder, or dropping sub-bands in a filter bank.

For instance, with G.722, you can omit the high frequency bits on the wire
(the upper 4 bits for each 8 bit sample), and get a 32 kbs narrow band coder
"for free".  If the decoder continues to run the QMF reconstriction filter
with 0 coefficients, you still have a wideband 16 kHz output (with no high
frequencies); if not you get a narrow band 8 kHz output.  I would not call
this "sample rate conversion", though it has a similar effect.

Since all three methods (and possibly others) have essentially the same
effect, we should not bias the selection / development process by forcing
one method to be used (by explicitly stating it in the requirements).

Dynamically changing sample rates on the system level adds some complexity
for RTP, since the timestamp granularity is supposed to be the sample rate.

BTW, dynamically changing the sample rate may be in conflict with the idea
of low-complexity compressed-domain mixing (even if the conversion is done
internally).

Stephen Botzko

On Tue, Apr 13, 2010 at 1:15 AM, Christian Hoene <[email-masked]>wrote:

> I would recommend to use only one nominal sampling rate (e.g. the sampling
> rate of the sound card) and let the codec do the conversion between the
> actually used and predefined.
>
> It might be useful to state that it is not recommended to use 44100 Hz,
> because the conversion to 16kHz and 32kHz is computational more demanding
> than 48kHz and requires more power/time.
>
> With best regards,
>
>  Christian
>
>
>
>
>
>
> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec
>

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 13 Apr 2010 06:41:35 -0500

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: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: stephen botzko <[email-masked]>
Date: Tue, 13 Apr 2010 09:20:42 -0400

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

---

From: "Christian Hoene" <[email-masked]>
Date: Tue, 13 Apr 2010 16:42:22 +0200

Hi,
 
It still might make sense to negotiate the maximal supported sampling rate via SDP or, if possible, to select one out of multiple
sampling rates, if the audio receiver can cope with multiple rates well. The internal sampling frequency of the codec NEEDS NOT to
be affected by the external sampling frequency.
 
However, the decoder might want to signal to the encoder that the decoding is requiring too many computational resources and that a
less complex coding mode (or a lower sampling frequency) should be taken.
 
Christian

---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of Tübingen 
Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532 
 <http://www.net.uni-tuebingen.de/> http://www.net.uni-tuebingen.de/
 
From: stephen botzko [mailto:[email-masked]] 
Sent: Tuesday, April 13, 2010 3:21 PM
To: Kevin P. Fleming
Cc: Christian Hoene; [email-masked]
Subject: Re: [codec] #8: Sample rates?

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 <[email-masked]> wrote:

---

From: stephen botzko <[email-masked]>
Date: Tue, 13 Apr 2010 10:56:01 -0400

This would make the signaling more complicated - personally I am not
convinced it is worth it.

I think a better avenue is to bound overall complexity, and to focus on
dynamically adapting to network conditions (as opposed to dynamic complexity
management).

You can't dynamically negotiate complexity in many scenarios anyway - for
instance it makes no sense if you are using multicast.

Stephen Botzko

On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene <[email-masked]>wrote:

>  Hi,
>
>
>
> It still might make sense to negotiate the maximal supported sampling rate
> via SDP or, if possible, to select one out of multiple sampling rates, if
> the audio receiver can cope with multiple rates well. The internal sampling
> frequency of the codec NEEDS NOT to be affected by the external sampling
> frequency.
>
>
>
> However, the decoder might want to signal to the encoder that the decoding
> is requiring too many computational resources and that a less complex coding
> mode (or a lower sampling frequency) should be taken.
>
>
>
> Christian
>
>
>
>
>
> http://www.net.uni-tuebingen.de/
>
>
>
> *From:* stephen botzko [mailto:[email-masked]]
> *Sent:* Tuesday, April 13, 2010 3:21 PM
> *To:* Kevin P. Fleming
> *Cc:* Christian Hoene; [email-masked]
> *Subject:* Re: [codec] #8: Sample rates?
>
>
>
> 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).
>

---

From: "Christian Hoene" <[email-masked]>
Date: Tue, 13 Apr 2010 17:18:02 +0200

Hi,
 
comments inline:

From: stephen botzko [mailto:[email-masked]] 
Sent: Tuesday, April 13, 2010 4:56 PM
To: Christian Hoene
Cc: [email-masked]
Subject: Re: [codec] #8: Sample rates?
 
This would make the signaling more complicated - personally I am not convinced it is worth it.  
CH: It is a difficult tradeoff. However, signaling overload is done in Skype.  Such as signaling might be very useful for mobile
devices, which want to save power and thus lower their CPU clock. Or wireless IP based headphones which do not have large batteries.
I am thinking of signaling the states: overloaded, fine, and low. That should be enough for most operational cases.

I think a better avenue is to bound overall complexity, and to focus on dynamically adapting to network conditions (as opposed to
dynamic complexity management). 
CH: I just like to remind that the good old TCP does support both: congestion control to adapt to network conditions and flow
control take into account an overloaded (=full) receiver.
You can't dynamically negotiate complexity in many scenarios anyway - for instance it makes no sense if you are using multicast.
CH: Multicast is out of scope anyhow. We are considering an interactive codec. 
CH: The conferencing scenario might be some more difficult to handle but will not a big problem.
Christian

Stephen Botzko

On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene < <mailto:[email-masked]> [email-masked]> wrote:
Hi,

 
Christian

 

Something like:

Stephen Botzko

---

From: stephen botzko <[email-masked]>
Date: Tue, 13 Apr 2010 12:26:02 -0400

TCP is a different case, since for this we are using RTCP to signal our
feedback, and I don't think it has the facility you are envisioning.

Also, I disagree with your presumption that multicast is out of scope.  I
don't know of any other packetization RFCs that expressly rule out
multicast, and multicast can be used for interactive applications.

This concept seems pretty theoretical to me.  If we need to manage
complexity / quality tradeoffs, why not just use profiles (as AVC/H.264
does) or create a low complexity variant (like G.729A).  I really don't see
the need for *dynamic* complexity management.

BTW, you seem to be assuming that a lower sample rate results in
significantly less complexity.  The savings there might not be as great as
you think, especially if the receiver needs to resample anyway (to prevent
those sound card limitations you were talking about before).

Stephen Botzko

On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene <[email-masked]>wrote:

> *Sent:* Tuesday, April 13, 2010 4:56 PM
> *To:* Christian Hoene
> *Cc:* [email-masked]
>
> CH: It is a difficult tradeoff. However, signaling overload is done in
> Skype.  Such as signaling might be very useful for mobile devices, which
> want to save power and thus lower their CPU clock. Or wireless IP based
> headphones which do not have large batteries. I am thinking of signaling the
> states: overloaded, fine, and low. That should be enough for most
> operational cases.
>
>
> CH: I just like to remind that the good old TCP does support both:
> congestion control to adapt to network conditions and flow control take into
> account an overloaded (=full) receiver.
>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 13 Apr 2010 12:41:57 -0400

I am not sure if this was decided, but should this new CODEC support music
encoding? If we don't plan to support music, we should probably stick to 16
Khz sampling rate. If we need music, I would suggest to have a 24 Khz (or
higher sampling rate) variant. I am not sure how many people here care about
a non-voice CODEC. For all the practical purposes I don't. I would argue,
at least, for a fixed 16 KHz sampling rate CODEC variant.

P.S. On the same note, does anybody here cares about using this CODEC with
multicast? Is there a single commercial multicast voice deployment? From
what I've seen all multicast does is making IETF voice standards harder to
understand or implement.

P.P.S. RTCP is almost universally not implemented. The biggest VoIP gateway
on the market does not generate RTCP. If we will rely on any RTCP
functionality for bandwidth control it will probably be ignored.
______________________________
Roman Shpount -  www.telurix.com

On Tue, Apr 13, 2010 at 12:26 PM, stephen botzko
<[email-masked]>wrote:

>>  On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene <
>> [email-masked]> wrote:
>>
>> Hi,
>>
>>
>>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 13 Apr 2010 10:00:38 -0700

On 04/13/2010 09:41 AM, Roman Shpount wrote:
> I am not sure if this was decided, but should this new CODEC support
> music encoding? If we don't plan to support music, we should probably
> stick to 16 Khz sampling rate. If we need music, I would suggest to have
> a 24 Khz (or higher sampling rate) variant. I am not sure how many
> people here care about a non-voice CODEC. For all the practical purposes
> I don't. 

I do.

> I would argue,  at least, for a fixed 16 KHz sampling rate
> CODEC variant.
> 
> P.S. On the same note, does anybody here cares about using this CODEC
> with multicast? Is there a single commercial multicast voice deployment?
> From what I've seen all multicast does is making IETF voice standards
> harder to understand or implement.

I think that would be a mistake to ignore multicast - not because of multicast
itself, but because of Xcast (RFC 5058) which is a promising technology to
replace centralized conference bridges.

> 
> P.P.S. RTCP is almost universally not implemented. The biggest VoIP
> gateway on the market does not generate RTCP. If we will rely on any
> RTCP functionality for bandwidth control it will probably be ignored.

Why is the opinion of gateway vendors relevant for an *Internet* codec?  Our
(S)AVP/RTP stack, that will implement this codec as soon we have a
specification, implements RTCP.

> Roman Shpount -  www.telurix.com <http://www.telurix.com>
> 
> 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     TCP is a different case, since for this we are using RTCP to signal
>     our feedback, and I don't think it has the facility you are
>     envisioning. 
> 
>     Also, I disagree with your presumption that multicast is out of
>     scope.  I don't know of any other packetization RFCs that expressly
>     rule out multicast, and multicast can be used for interactive
>     applications.
> 
>     complexity / quality tradeoffs, why not just use profiles (as
>     AVC/H.264 does) or create a low complexity variant (like G.729A).  I
>     really don't see the need for dynamic complexity management.
> 
>     significantly less complexity.  The savings there might not be as
>     great as you think, especially if the receiver needs to resample
>     anyway (to prevent those sound card limitations you were talking
>     about before).
> 
>     Stephen Botzko
> 
>     On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         Hi,
> 
>          
> 
>         comments inline:
> 
>          
> 
>          
> 
>         * From: * stephen botzko [mailto:[email-masked]
>         <mailto:[email-masked]>]
>         *Cc:* [email-masked] <mailto:[email-masked]>
> 
>         CH: It is a difficult tradeoff. However, signaling overload is
>         done in Skype.  Such as signaling might be very useful for
>         mobile devices, which want to save power and thus lower their
>         CPU clock. Or wireless IP based headphones which do not have
>         large batteries. I am thinking of signaling the states:
>         overloaded, fine, and low. That should be enough for most
>         operational cases.
> 
> 
>         I think a better avenue is to bound overall complexity, and to
>         focus on dynamically adapting to network conditions (as opposed
>         to dynamic complexity management).
> 
>         CH: I just like to remind that the good old TCP does support
>         both: congestion control to adapt to network conditions and flow
>         You can't dynamically negotiate complexity in many scenarios
>         anyway - for instance it makes no sense if you are using multicast.
> 
>         On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene
>         <[email-masked] <mailto:[email-masked]> > wrote:
> 
>         Hi,
> 
>          
> 
>         It still might make sense to negotiate the maximal supported
>         sampling rate via SDP or, if possible, to select one out of
>         multiple sampling rates, if the audio receiver can cope with
>         multiple rates well. The internal sampling frequency of the
>         codec NEEDS NOT to be affected by the external sampling frequency.
> 
>          
> 
>         However, the decoder might want to signal to the encoder that
>         the decoding is requiring too many computational resources and
>         that a less complex coding mode (or a lower sampling frequency)
>         should be taken.
> 
>          
> 
>         Christian
> 
>          
> 
>          
> 
>         * From: * stephen botzko [mailto:[email-masked]
>         <mailto:[email-masked]>]
>         *Cc:* Christian Hoene; [email-masked] <mailto:[email-masked]>
>         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
>         <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         stephen botzko wrote:
> 

-- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 13 Apr 2010 10:08:23 -0700

> #8: Sample rates?

On the subject of multiple clock rates in RTP, please have a look to this I-D
that is discussed in the AVT WG:

http://tools.ietf.org/id/draft-petithuguenin-avt-multiple-clock-rates-01.txt

Here's the slides used for the presentation in Anaheim:

http://www.ietf.org/proceedings/10mar/slides/avt-6.pdf

---

From: stephen botzko <[email-masked]>
Date: Tue, 13 Apr 2010 13:29:05 -0400

Superwideband (and even fullband) do make speech somewhat more intelligible,
and also reduce listener fatigue.  Telepresence and other videoconferencing
equipment use those acoustic bandwidths today, so it would be nice if CODEC
supported at least superwideband also.

Personally I see some value in carriage of music.  Sometimes our equipment
is used for music performance.  Distance learning is another use case where
music has some value, since course and training materials frequently do
include videos with music.  Though of course conversational speech is the
dominant use case.

BTW, Videoconferencing devices do almost always support RTCP.  It is
regrettable that so many VOIP devices do not.  Anyway, I do not think our
charter scope includes invention of a new mechanism for signaling the
network quality.

Stephen Botzko

On Tue, Apr 13, 2010 at 12:41 PM, Roman Shpount <[email-masked]> wrote:

> On Tue, Apr 13, 2010 at 12:26 PM, stephen botzko <[email-masked]
> > wrote:
>
>> On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene <[email-masked]
>> > wrote:
>>
>>>  Hi,
>>>
>>>
>>>
>>> comments inline:
>>>
>>>
>>>
>>>
>>>
>>> It still might make sense to negotiate the maximal supported sampling
>>> rate via SDP or, if possible, to select one out of multiple sampling rates,
>>> if the audio receiver can cope with multiple rates well. The internal
>>> sampling frequency of the codec NEEDS NOT to be affected by the external
>>> sampling frequency.
>>>
>>>
>>>
>>> However, the decoder might want to signal to the encoder that the
>>> decoding is requiring too many computational resources and that a less
>>> complex coding mode (or a lower sampling frequency) should be taken.
>>>
>>>
>>>
>>> Christian
>>>
>>>
>>>
>>>
>>>
>>> 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
>>>

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 13 Apr 2010 12:46:17 -0500

stephen botzko wrote:
> Superwideband (and even fullband) do make speech somewhat more
> intelligible, and also reduce listener fatigue.  Telepresence and other
> videoconferencing equipment use those acoustic bandwidths today, so it
> would be nice if CODEC supported at least superwideband also.

They also greatly enhance the accuracy of speech recognition... and
vendors are starting to produce recognition platforms using wideband
sample libraries now, so it wouldn't hurt to be one step ahead.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 13 Apr 2010 14:11:12 -0400

I will not argue superwideband vs wideband, even though we did some, not
very scientific, blind tests, and in most cases people (especially men)
cannot even distinguish wideband from superwideband when listening to voice
samples. Only a very small percentage of voice energy is even present above
8 Khz.

Music on the other hand, especially past 24Khz sampling rate, gets affected
by the CODEC more then by bandwidth. For instance 8KHz G.711 encoded music
sounds poor, but reasonable, and G.729 encoded music cannot be listened to.
In most cases (apart from critical listening), music sampled at 16Khz is
acceptable, especially for generation iPod.

My remark about RTPC was to try to develop a CODEC that will function
properly with RTCP absent. If we require RTCP based mechanisms in order for
the CODEC to operate properly, this can impede the adoption of this CODEC.
In no way do I propose to create new signaling mechanisms.
______________________________
Roman Shpount - www.telurix.com

On Tue, Apr 13, 2010 at 1:29 PM, stephen botzko <[email-masked]>wrote:

> videoconferencing equipment use those acoustic bandwidths today, so it would
> be nice if CODEC supported at least superwideband also.
>
>> gateway on the market does not generate RTCP. If we will rely on any RTCP
>> On Tue, Apr 13, 2010 at 12:26 PM, stephen botzko <
>> [email-masked]> wrote:
>>
>>> On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene <
>>>> Skype.  Such as signaling might be very useful for mobile devices,
>>>> which want to save power and thus lower their CPU clock. Or wireless IP
>>>> based headphones which do not have large batteries. I am thinking of
>>>> signaling the states: overloaded, fine, and low. That should be enough for
>>>> most operational cases.
>>>>
>>>>
>>>> You can't dynamically negotiate complexity in many scenarios anyway -
>>>> for instance it makes no sense if you are using multicast.
>>>>
>>>> bandwidth management) from multiple fixed sample rates; and I agree that is
>>>> a key distinction.
>>>>

---

From: stephen botzko <[email-masked]>
Date: Tue, 13 Apr 2010 14:43:11 -0400

I will not argue superwideband vs wideband, even though we did some, not
very scientific, blind tests, and in most cases people (especially men)
cannot even distinguish wideband from superwideband when    listening to
voice samples. Only a very small percentage of voice energy is even present
above 8 Khz.
Though there isn't much voice energy over 8 kHz, in our (equally
unscientific) tests, sibilants and fricatives are easier to distinguish if
you are using superwideband or better.  That was one reason we added Annec C
to G.722.1.

Fullband is (IMHO) a specsmanship thing for speech (and probably for music
also for most of us).  Though it may not be that hard to get it, if we are
shooting for superwideband anyway.

Stephen Botzko

On Tue, Apr 13, 2010 at 2:11 PM, Roman Shpount <[email-masked]> wrote:

>> On Tue, Apr 13, 2010 at 12:41 PM, Roman Shpount <[email-masked]>wrote:
>>
>>> music encoding? If we don't plan to support music, we should probably stick
>>> to 16 Khz sampling rate. If we need music, I would suggest to have a 24 Khz
>>> (or higher sampling rate) variant. I am not sure how many people here care
>>> about a non-voice CODEC. For all the practical purposes I don't. I would
>>> argue,  at least, for a fixed 16 KHz sampling rate CODEC variant.
>>>
>>> From what I've seen all multicast does is making IETF voice standards harder
>>> to understand or implement.
>>>
>>>> Also, I disagree with your presumption that multicast is out of scope.
>>>> I don't know of any other packetization RFCs that expressly rule out

---

From: "Benjamin M. Schwartz" <[email-masked]>
Date: Tue, 13 Apr 2010 14:59:50 -0400

> shooting for superwideband anyway.

I think scaling up to fullband and total transparency is important, so
that we never have to do this* again.

--Ben

*: "this" being standardizing a low-latency audio codec.  Of course, we
can do this again if we want to, but we have an opportunity to be somewhat
"future-proof", and we might as well take it.

---

From: "Raymond (Juin-Hwey) Chen" <[email-masked]>
Date: Tue, 13 Apr 2010 12:23:14 -0700

I would agree with Roman that for speech the difference between wideband (16 kHz sampling) and super-wideband/full-band (32 ~ 48 kHz sampling) is there but very small and many people cannot even distinguish between them, while for music the difference can be much more noticeable. From all the codec WG emails dating back to last year, it appears to me that most people want the IETF codec to handle music as well as speech.  Therefore, it seems appropriate to have the maximum sampling rate up to 48 kHz if we want to the codec to handle music.

Regarding the dynamic switching of the sampling rate or audio bandwidth, if this is to be done, I think we need to be careful not to change the audio bandwidth too frequently, otherwise the frequent change of the audio bandwidth can be quite disturbing to the listener.  It would certainly be disturbing to me personally if the audio bandwidth changes more frequently than once every few seconds, but if it changes once every few minutes, that's probably tolerable to me.

Raymond

From: [email-masked] [mailto:[email-masked]] On Behalf Of stephen botzko
Sent: Tuesday, April 13, 2010 11:43 AM
To: Roman Shpount
Cc: [email-masked]
Subject: Re: [codec] #8: Sample rates?

I will not argue superwideband vs wideband, even though we did some, not very scientific, blind tests, and in most cases people (especially men) cannot even distinguish wideband from superwideband when    listening to voice samples. Only a very small percentage of voice energy is even present above 8 Khz.
Though there isn't much voice energy over 8 kHz, in our (equally unscientific) tests, sibilants and fricatives are easier to distinguish if you are using superwideband or better.  That was one reason we added Annec C to G.722.1.

Fullband is (IMHO) a specsmanship thing for speech (and probably for music also for most of us).  Though it may not be that hard to get it, if we are shooting for superwideband anyway.

Stephen Botzko

On Tue, Apr 13, 2010 at 2:11 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
I will not argue superwideband vs wideband, even though we did some, not very scientific, blind tests, and in most cases people (especially men) cannot even distinguish wideband from superwideband when listening to voice samples. Only a very small percentage of voice energy is even present above 8 Khz.

Music on the other hand, especially past 24Khz sampling rate, gets affected by the CODEC more then by bandwidth. For instance 8KHz G.711 encoded music sounds poor, but reasonable, and G.729 encoded music cannot be listened to. In most cases (apart from critical listening), music sampled at 16Khz is acceptable, especially for generation iPod.

My remark about RTPC was to try to develop a CODEC that will function properly with RTCP absent. If we require RTCP based mechanisms in order for the CODEC to operate properly, this can impede the adoption of this CODEC. In no way do I propose to create new signaling mechanisms.

______________________________
Roman Shpount - www.telurix.com<http://www.telurix.com>

On Tue, Apr 13, 2010 at 1:29 PM, stephen botzko <[email-masked]<mailto:[email-masked]>> wrote:
Superwideband (and even fullband) do make speech somewhat more intelligible, and also reduce listener fatigue.  Telepresence and other videoconferencing equipment use those acoustic bandwidths today, so it would be nice if CODEC supported at least superwideband also.

Personally I see some value in carriage of music.  Sometimes our equipment is used for music performance.  Distance learning is another use case where music has some value, since course and training materials frequently do include videos with music.  Though of course conversational speech is the dominant use case.

BTW, Videoconferencing devices do almost always support RTCP.  It is regrettable that so many VOIP devices do not.  Anyway, I do not think our charter scope includes invention of a new mechanism for signaling the network quality.

Stephen Botzko

On Tue, Apr 13, 2010 at 12:41 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
I am not sure if this was decided, but should this new CODEC support music encoding? If we don't plan to support music, we should probably stick to 16 Khz sampling rate. If we need music, I would suggest to have a 24 Khz (or higher sampling rate) variant. I am not sure how many people here care about a non-voice CODEC. For all the practical purposes I don't. I would argue,  at least, for a fixed 16 KHz sampling rate CODEC variant.

P.S. On the same note, does anybody here cares about using this CODEC with multicast? Is there a single commercial multicast voice deployment? From what I've seen all multicast does is making IETF voice standards harder to understand or implement.

P.P.S. RTCP is almost universally not implemented. The biggest VoIP gateway on the market does not generate RTCP. If we will rely on any RTCP functionality for bandwidth control it will probably be ignored.
______________________________
Roman Shpount -  www.telurix.com<http://www.telurix.com>

On Tue, Apr 13, 2010 at 12:26 PM, stephen botzko <[email-masked]<mailto:[email-masked]>> wrote:
TCP is a different case, since for this we are using RTCP to signal our feedback, and I don't think it has the facility you are envisioning.

Also, I disagree with your presumption that multicast is out of scope.  I don't know of any other packetization RFCs that expressly rule out multicast, and multicast can be used for interactive applications.

This concept seems pretty theoretical to me.  If we need to manage complexity / quality tradeoffs, why not just use profiles (as AVC/H.264 does) or create a low complexity variant (like G.729A).  I really don't see the need for dynamic complexity management.

BTW, you seem to be assuming that a lower sample rate results in significantly less complexity.  The savings there might not be as great as you think, especially if the receiver needs to resample anyway (to prevent those sound card limitations you were talking about before).

Stephen Botzko
On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

comments inline:

From: stephen botzko [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, April 13, 2010 4:56 PM
To: Christian Hoene
Cc: [email-masked]<mailto:[email-masked]>

This would make the signaling more complicated - personally I am not convinced it is worth it.
CH: It is a difficult tradeoff. However, signaling overload is done in Skype.  Such as signaling might be very useful for mobile devices, which want to save power and thus lower their CPU clock. Or wireless IP based headphones which do not have large batteries. I am thinking of signaling the states: overloaded, fine, and low. That should be enough for most operational cases.

I think a better avenue is to bound overall complexity, and to focus on dynamically adapting to network conditions (as opposed to dynamic complexity management).
CH: I just like to remind that the good old TCP does support both: congestion control to adapt to network conditions and flow control take into account an overloaded (=full) receiver.
You can't dynamically negotiate complexity in many scenarios anyway - for instance it makes no sense if you are using multicast.
CH: Multicast is out of scope anyhow. We are considering an interactive codec.
CH: The conferencing scenario might be some more difficult to handle but will not a big problem.
Christian

Stephen Botzko
On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

It still might make sense to negotiate the maximal supported sampling rate via SDP or, if possible, to select one out of multiple sampling rates, if the audio receiver can cope with multiple rates well. The internal sampling frequency of the codec NEEDS NOT to be affected by the external sampling frequency.

However, the decoder might want to signal to the encoder that the decoding is requiring too many computational resources and that a less complex coding mode (or a lower sampling frequency) should be taken.

Christian

From: stephen botzko [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, April 13, 2010 3:21 PM
To: Kevin P. Fleming
Cc: Christian Hoene; [email-masked]<mailto:[email-masked]>
Subject: Re: [codec] #8: Sample rates?

Something like:

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 <[email-masked]<mailto:[email-masked]>> wrote:

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]<mailto:[email-masked]>
Check us out at www.digium.com<http://www.digium.com> & www.asterisk.org<http://www.asterisk.org>

_______________________________________________
codec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/codec

---

From: stephen botzko <[email-masked]>
Date: Tue, 13 Apr 2010 16:03:29 -0400

I agree.

The changes in audio bandwidth will certainly be audible, and personally I
would prefer a stable experience.

Also, increasing the audio bandwidth might result in audible temporary echo
(in the newly opened frequencies), since the acoustic echo cancellers will
often need to re-adapt.  The acoustic feedback paths can change pretty
quickly at higher frequencies.

Stephen Botzko

On Tue, Apr 13, 2010 at 3:23 PM, Raymond (Juin-Hwey) Chen <
[email-masked]> wrote:

>  I would agree with Roman that for speech the difference between wideband
> (16 kHz sampling) and super-wideband/full-band (32 ~ 48 kHz sampling) is
> there but very small and many people cannot even distinguish between them,
> while for music the difference can be much more noticeable. From all the
> codec WG emails dating back to last year, it appears to me that most people
> want the IETF codec to handle music as well as speech.  Therefore, it seems
> appropriate to have the maximum sampling rate up to 48 kHz if we want to the
> codec to handle music.
>
>
>
> Regarding the dynamic switching of the sampling rate or audio bandwidth, if
> this is to be done, I think we need to be careful not to change the audio
> bandwidth too frequently, otherwise the frequent change of the audio
> bandwidth can be quite disturbing to the listener.  It would certainly be
> disturbing to me personally if the audio bandwidth changes more frequently
> than once every few seconds, but if it changes once every few minutes,
> that’s probably tolerable to me.
>
>
>
> Raymond
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *stephen botzko
> *Sent:* Tuesday, April 13, 2010 11:43 AM
> *To:* Roman Shpount
>
> *Cc:* [email-masked]
>    On Tue, Apr 13, 2010 at 1:29 PM, stephen botzko <

---

From: Koen Vos <[email-masked]>
Date: Tue, 13 Apr 2010 16:48:18 -0700

My 2 cents on this thread:

- Going beyond WB quality matters a lot, even for speech.  See for  
example slides 2, 3 of  
http://www.ietf.org/proceedings/10mar/slides/codec-3.pdf.  Agree with  
Ben that we might as well go full-band.

- The codec has 3 sampling rates:
   1. Encoder API
   2. Codec internal (not strictly sampling rate, more audio bandwidth  
as Stephen pointed out)
   3. Decoder API
I don't see a reason to impose that some or all of these be identical.  
  For (conference) mixing of several streams it helps if all decoders  
run at the same API sampling rate. It would be unreasonable to require  
that every encoder also runs at that API sampling rate.  Some encoders  
may for instance sit in a PSTN gateway, dealing strictly with  
narrowband signals.

- To keep RTP timestamps simple, they could always be based on the  
same sampling rate, irrespective of any of the ones above. Maybe 48  
kHz is a good choice?

- Sometimes a decoder runs on hardware with limited audio bandwidth  
playback capabilities (e.g. mobile devices).  In those cases it helps  
if the decoder can request a maximum internal audio bandwidth to the  
encoder, during call setup. Otherwise the encoder may be wasting bits  
on unused audio spectrum.  So I agree with Christian on this.

- Agree with Raymond that fast switching of audio bandwidth sounds  
unpleasant.  SILK has a hysteresis mechanism for this, and we rarely  
get more than one or two switches during a Skype call.

best,
koen.

Quoting stephen botzko <[email-masked]>:

>> that's probably tolerable to me.
>>
>>
>>
>> Raymond
>>
>>
>>

---

From: stephen botzko <[email-masked]>
Date: Tue, 13 Apr 2010 20:23:40 -0400

I am not sure exactly what you mean by  "API rate".  Seems to me that the
reference encoder source code might accept any sample rate, but convert it
to 48 kHz before encoding. If that is what you mean, then the two API rates
are never signaled?

I rather like the idea of negotiating maximum audio bandwidth.  For me that
is different from dynamic complexity management, and is being signaled for a
different purpose (wasting coded bits on unheard spectrum degrades the
quality of the heard spectrum). Signaling the bandwidth, and defining the
internal codec rate as fullband should let us lock down the RTP timestamp
rate at 48 kHz (which I think is desirable).

Stephen Botzko

On Tue, Apr 13, 2010 at 7:48 PM, Koen Vos <[email-masked]> wrote:

> - Going beyond WB quality matters a lot, even for speech.  See for example
> slides 2, 3 of http://www.ietf.org/proceedings/10mar/slides/codec-3.pdf.
>  Agree with Ben that we might as well go full-band.
>
>  2. Codec internal (not strictly sampling rate, more audio bandwidth as
> Stephen pointed out)
>  3. Decoder API
> I don't see a reason to impose that some or all of these be identical.  For
> (conference) mixing of several streams it helps if all decoders run at the
> same API sampling rate. It would be unreasonable to require that every
> encoder also runs at that API sampling rate.  Some encoders may for instance
> sit in a PSTN gateway, dealing strictly with narrowband signals.
>
> - To keep RTP timestamps simple, they could always be based on the same
> sampling rate, irrespective of any of the ones above. Maybe 48 kHz is a good
> choice?
>
> playback capabilities (e.g. mobile devices).  In th?ose cases it helps if
> the decoder can request a maximum internal audio bandwidth to the encoder,
> during call setup. Otherwise the encoder may be wasting bits on unused audio
> spectrum.  So I agree with Christian on this.
>
> unpleasant.  SILK has a hysteresis mechanism for this, and we rarely get
> more than one or two switches during a Skype call.
>
> best,
> koen.
>
>
>
>
>>> voice
>>> would
>>> music
>>> with
>>> gateway
>>> rate
>>> decoding
>>> fixed

---

From: Koen Vos <[email-masked]>
Date: Tue, 13 Apr 2010 17:57:25 -0700

Quoting stephen botzko:
> If that is what you mean, then the two API rates are never signaled?

Right, that's what I meant.

koen.

---

From: "Benjamin M. Schwartz" <[email-masked]>
Date: Tue, 13 Apr 2010 21:05:18 -0400

stephen botzko wrote:
> quality of the heard spectrum).

1. Why would high frequencies be unheard?  Cheap speakers and microphones
have difficulties with low frequencies, but not high frequencies, and
routinely go all the way up past the limit of hearing.

2. Why would it need to be negotiated?  For a suitably designed format,
the encoder could choose not to waste bits on high frequencies without any
negotiation or extra signalling.

> Signaling the bandwidth, and defining the

I do agree that having "only one mode" would be ideal, to maximize
interoperability.  I wonder whether we can achieve high enough
computational efficiency for this to be viable.

--Ben

---

From: Koen Vos <[email-masked]>
Date: Tue, 13 Apr 2010 18:36:02 -0700

> routinely go all the way up past the limit of hearing.

Not all hardware supports arbitrary/high sampling rates.  PSTN  
gateways don't go above 8 kHz.  Same for some mobile devices.

> negotiation or extra signalling.

Without signaling, how would the encoder know that the farend decoder  
will not take advantage of frequencies above a certain threshold?

> computational efficiency for this to be viable.

Changing the RTP timestamp sampling rate causes no computational  
complexity, does it?  Perhaps an extra multiplication for each packet  
or so?  The point was that RTP timestamp sampling rate should  
disconnected from the actual audio signals.

koen.

---

From: "Benjamin M. Schwartz" <[email-masked]>
Date: Tue, 13 Apr 2010 21:54:48 -0400

Koen Vos wrote:
> Not all hardware supports arbitrary/high sampling rates.  PSTN gateways
> don't go above 8 kHz.  Same for some mobile devices.

True.

> will not take advantage of frequencies above a certain threshold?

When I say signalling, I mean signalling within the codec bitstream.  The
encoder can change its behavior based on knowledge of the receiver's
configuration, but the bitstream does not need any extra signalling to
indicate the change in behavior.

> complexity, does it?  Perhaps an extra multiplication for each packet or
> so?  The point was that RTP timestamp sampling rate should disconnected
> from the actual audio signals.

Right, but Stephen also suggested "defining the internal codec rate as
fullband".  From this, I imagined a scenario in which all (compliant) IWAC
implementations MUST decode all IWAC streams, which always have a sampling
rate of 48 KHz.  I think this is a great idea, to achieve really good
interoperability.

If the receiver is a PSTN gateway, then an "internal codec rate" of 8 KHz
would presumably produce as good quality/bitrate with lower encoder and
decoder complexity.  However, if we can make IWAC sufficiently
low-complexity, operating at 48 KHz may be acceptable.  It will help if we
can structure the codec so that operating at lower bandwidth is very
efficient.  For example, it may be possible to structure a transform codec
such that unneeded high frequencies can cheaply be zero'd on encode and
ignored on decode.

--Ben

---

From: stephen botzko <[email-masked]>
Date: Tue, 13 Apr 2010 22:55:08 -0400

When I said signaling I meant SDP, not anything in the bitstream itself.  I
was not excluding audio bandwidth changes mid-call as part of network
adaptation.  Though as we all agree this needs to be carefully designed.

I agree it is best if the decoder does not require any knowledge of the SDP
negotiation (or any other information beyond the RTP packet stream itself)
in order to correctly decode the audio -- which I think is what you were
concerned about.

It would be a nice property if reducing the acoustic bandwidth also allowed
the MIPS to be reduced, but I do not think it is a requirement;  I'd
personally rather manage complexity with a Low Complexity profile (if that
is really needed), since then I could keep the acoustic bandwidth (accepting
a higher bit rate instead).

Stephen Botzko

---

From: Roman Shpount <[email-masked]>
Date: Wed, 14 Apr 2010 00:37:23 -0400

To be honest, your slides show that SILK works better at superwideband, not
that superwideband is better then wideband. Normally, G.711 at 8 KHz has a
higher MOS (4.4) score then SILK at superwideband (3.9). To compare wideband
vs superwideband (or full rate) you need to compare 16 Khz linear PCM vs
superwideband (or full rate) linear PCM. As far as full rate is concerned,
most men cannot hear above 12-14 khz. In side by side listening tests we
did, using high end headsets (AKG K-701, Sennheiser HD 650) and professional
DAC/headphone AMP (Benchmark DAC-1) using prerecorded voice samples
(English, adult voices, no kids), nobody could distinguish wideband from
superwideband, but this can be us, our samples, and untrained listeners.

I understand the motivation for defining the codec that will go all the way
to full band, but I think, it would make sense to define at least two codec
profiles: 16 KHz mono, and compatible full rate codec with support for joint
multichannel encoding, similar to AMR-WB and AMR-WB+.
_____________________________
Roman Shpount - www.telurix.com

On Tue, Apr 13, 2010 at 7:48 PM, Koen Vos <[email-masked]> wrote:

> playback capabilities (e.g. mobile devices).  In those cases it helps if the
> decoder can request a maximum internal audio bandwidth to the encoder,

---

From: Koen Vos <[email-masked]>
Date: Tue, 13 Apr 2010 22:18:51 -0700

Roman - good observation.

However, these graphs were based on only calls where the codec ran at  
the maximum bitrate (30 kbps for SILK WB). At this bitrate, SILK is  
(virtually) transparent, according to Dynastat tests we did. See the  
MOS scores here
https://developer.skype.com/silk?action=AttachFile&do=get&target=SILKDataSheet.pdf

There could be many reasons why we got only MOS scores around 3.8 in  
the client-based testing..  Perhaps users in an official listening  
test score more optimistically than anonymous users behind their  
PCs... Or factors outside the codec, like background noise, a crappy  
headset or network problems, may have limited the audio quality.

(There is one minor "flaw" in the test: SILK SWB has a higher maximum  
bitrate (40 kbps) than SILK WB; and the other modes have even lower  
max rates.  So SWB calls that were included (>= 40 kbps) had on  
average better network bandwidth than WB calls (>= 30 kbps).  This may  
have meant that SWB calls just had better networks with less packet  
loss etc., on average.  However, if we exclude the filtering on max  
bitrates then the pattern still exists, just slightly weakened.  And  
in that case, SILK SWB would occasionally be running in WB mode or  
less, because it automatically switches down at lower bitrates.)

best,
koen.

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 14 Apr 2010 01:30:16 -0400

On 2010-04-14 00:37, Roman Shpount wrote:
> To be honest, your slides show that SILK works better at superwideband,
> not that superwideband is better then wideband.

Then I suggest you have a look at the left graph in slide 7 of: 
http://www.ietf.org/proceedings/10mar/slides/codec-6.pdf
The blue bars show speech quality and the bar that's marked with "7 kHz" 
means 7 kHz bandwidth, which means *uncompressed* wideband audio.

> Normally, G.711 at 8 KHz
> has a higher MOS (4.4) score then SILK at superwideband (3.9).

Note that MOS is not an absolute measurement and MOS scored can only be 
compared when they come from the same test.

> To
> compare wideband vs superwideband (or full rate) you need to compare 16
> Khz linear PCM vs superwideband (or full rate) linear PCM. As far as
> full rate is concerned, most men cannot hear above 12-14 khz.

I disagree here. Don't know where you got that data, but it doesn't 
sound right. FTR, like many others, I'm over 30 and still easily hear 
the NSTC hozontal sync (15.3 kHz) coming out of CRT TVs.

> In side by
> side listening tests we did, using high end headsets (AKG K-701,
> Sennheiser HD 650) and professional DAC/headphone AMP (Benchmark DAC-1)
> using prerecorded voice samples (English, adult voices, no kids), nobody
> could distinguish wideband from superwideband, but this can be us, our
> samples, and untrained listeners.

Well, my listening tests that I linked above clearly disagree with your 
results. Maybe you were using samples that were already low-passed at 7 kHz!

Not saying that wideband (and even narrowband) doesn't have a use, just 
that full-band is definitely useful.

Cheers,

	Jean-Marc

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 14 Apr 2010 08:33:54 +0200 (CEST)

> "future-proof", and we might as well take it.

Developing an Internet audio transmission standard without being able to 
handle music would be a mistake in my opinion. Most people think that 
128kbit/s mp3 is good enough for music, and I think the codec chosen 
should have ability to deliver equivalent music sound quality.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Roman Shpount <[email-masked]>
Date: Wed, 14 Apr 2010 02:51:06 -0400

Actually, since we are on the topic of full band, should this CODEC also
support 20 and 24-bit audio samples? In music I can hear the difference
between 16 and 24 bit encoded material.
_____________________________
Roman Shpount - www.telurix.com

---

From: "Christian Hoene" <[email-masked]>
Date: Wed, 14 Apr 2010 12:59:15 +0200

Hi ,
 
comments inline:
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of stephen botzko
Sent: Wednesday, April 14, 2010 4:55 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [codec] #8: Sample rates?
 
When I said signaling I meant SDP, not anything in the bitstream itself.  I was not excluding audio bandwidth changes mid-call as
part of network adaptation.  Though as we all agree this needs to be carefully designed.

I agree it is best if the decoder does not require any knowledge of the SDP negotiation (or any other information beyond the RTP
packet stream itself) in order to correctly decode the audio -- which I think is what you were concerned about.
CH: Negotiating codec parameters with SDP has a long tradition. Take for example µLaw (RTP payload type 0): Here you negotiate the
sampling rate. Also, the number of channels are negotiated for many codecs. I think sampling rate and number of channels can be done
with SDP. However, I would avoid other codec specific parameters. Especially, in case of AMR the negotiation is quite complex should
be avoided for the Internet  CODEC.
Christian

It would be a nice property if reducing the acoustic bandwidth also allowed the MIPS to be reduced, but I do not think it is a
requirement;  I'd personally rather manage complexity with a Low Complexity profile (if that is really needed), since then I could
keep the acoustic bandwidth (accepting a higher bit rate instead).

Stephen Botzko
On Tue, Apr 13, 2010 at 9:54 PM, Benjamin M. Schwartz <[email-masked]> wrote:
True.

--Ben

---

From: stephen botzko <[email-masked]>
Date: Wed, 14 Apr 2010 07:32:15 -0400

Hi Christian

I think I might not have been very clear.

Certainly SDP negotiation of parameters is the normal practice, and with
good reason.

I agree it is best if the decoder does not require any knowledge of the SDP
negotiation (or any other information beyond the RTP packet stream itself)
in order to correctly decode the audio
My point here was not that SDP negotiation should be avoided.  I was tryiing
to say that it is best if the RTP payload is complete (in the sense that it
can be fully decoded even if you ignore the signaling, as long as you  know
the codec itself).  For instance, if you negotiate the number of channels,
it should be possible for the decoder to identify the number of channels
from the RTP payload.

There are codecs where this is not done.  Though personally I think it is
the best architectural approach, even if it costs some payload bits.  One
reason is that I think changing modes should be seamless, and there is a
race condition between the signaling and the RTP payload. If you are
adapting to network conditions, it is particularly useful to change on the
fly.

On Wed, Apr 14, 2010 at 6:59 AM, Christian Hoene <[email-masked]>wrote:

> *Sent:* Wednesday, April 14, 2010 4:55 AM
> *To:* [email-masked]
>
> *Cc:* [email-masked]
> When I said signaling I meant SDP, not anything in the bitstream itself.
> I was not excluding audio bandwidth changes mid-call as part of network
> CH: Negotiating codec parameters with SDP has a long tradition. Take for
> example µLaw (RTP payload type 0): Here you negotiate the sampling rate.
> Also, the number of channels are negotiated for many codecs. I think
> sampling rate and number of channels can be done with SDP. However, I would
> avoid other codec specific parameters. Especially, in case of AMR the
> negotiation is quite complex should be avoided for the Internet  CODEC.
>
> Christian
>
>

---

From: "Roni Even" <[email-masked]>
Date: Wed, 14 Apr 2010 14:35:54 +0300

Hi,

Negotiation of codec parameters is not a tradition it  is needed if there
are optional modes that the decoder can support in order to allow the sender
to know if the receiver can receive the specific mode. If there are
mandatory modes you may be able to provide the information in-band but this
is not negotiation. Also note that while the signaling may use reliable
channel the media path is not reliable and may suffer packet loss that may
cause the loss of important parameters. We have such example in the H.264
parameter sets where they can be carried in the SDP for reliability on
in-band as part of the payload.

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christian Hoene
Sent: Wednesday, April 14, 2010 1:59 PM
To: 'stephen botzko'
Cc: [email-masked]
Subject: Re: [codec] #8: Sample rates?

Hi ,

comments inline:

From: [email-masked] [mailto:[email-masked]] On Behalf Of
stephen botzko
Sent: Wednesday, April 14, 2010 4:55 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [codec] #8: Sample rates?

Christian

Stephen Botzko

On Tue, Apr 13, 2010 at 9:54 PM, Benjamin M. Schwartz
<[email-masked]> wrote:

True.

--Ben

---

From: stephen botzko <[email-masked]>
Date: Wed, 14 Apr 2010 07:51:35 -0400

Good points, thanks for clarifying..

Personally I favor carrying those H.264 parameter sets on the media path,
since there are situations (switched multipoint calls for one) where the
timing matters.  With that use case, if reliable-but-too-late delivery
occurs, there are decoding errors even if there is no packet loss.

Though of course SDP transmission alone may be suitable for other
applications, and it is perfectly legal to send them both ways.

Stephen Botzko

2010/4/14 Roni Even <[email-masked]>

> Of *Christian Hoene
> *Sent:* Wednesday, April 14, 2010 1:59 PM
> *To:* 'stephen botzko'
>
> *Cc:* [email-masked]

---

From: "Christian Hoene" <[email-masked]>
Date: Wed, 14 Apr 2010 14:08:29 +0200

Hi,
 
I am fine with dropping any SDP negotiation on codec parameters including sampling rate and channels. I like the idea of splitting
signaling and transportation issues.
 
But one question remain. We had the question on limiting the complexity for some kind of devices by choosing a lower sampling rate
or a low number of channels. Shall this negotiation be done with SDP or inband?
 
Christian

From: stephen botzko [mailto:[email-masked]] 
Sent: Wednesday, April 14, 2010 1:52 PM
To: Roni Even
Cc: Christian Hoene; [email-masked]
Subject: Re: [codec] #8: Sample rates?

Personally I favor carrying those H.264 parameter sets on the media path, since there are situations (switched multipoint calls for
one) where the timing matters.  With that use case, if reliable-but-too-late delivery occurs, there are decoding errors even if
there is no packet loss.  

Though of course SDP transmission alone may be suitable for other applications, and it is perfectly legal to send them both ways.

Stephen Botzko
2010/4/14 Roni Even <[email-masked]>
Hi,
Negotiation of codec parameters is not a tradition it  is needed if there are optional modes that the decoder can support in order
to allow the sender to know if the receiver can receive the specific mode. If there are mandatory modes you may be able to provide
the information in-band but this is not negotiation. Also note that while the signaling may use reliable channel the media path is
not reliable and may suffer packet loss that may cause the loss of important parameters. We have such example in the H.264 parameter
sets where they can be carried in the SDP for reliability on in-band as part of the payload.
 
Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of Christian Hoene
Sent: Wednesday, April 14, 2010 1:59 PM
To: 'stephen botzko'

Cc: [email-masked]
 
Hi ,
 
comments inline:

Stephen Botzko
True.

--Ben

---

From: stephen botzko <[email-masked]>
Date: Wed, 14 Apr 2010 08:25:22 -0400

All negotiation should be done with SDP (and should *never* be done in-band)

And the RTP transport should be robust enough to permit seamless changes to
any mode that is consistent with the negotiation (with no signaling).

The first point I think is essential.  The second reflects my own view on
how RTP packetization should be done.

Stephen Botzko

On Wed, Apr 14, 2010 at 8:08 AM, Christian Hoene <[email-masked]>wrote:

>  Hi,
>
>
>
> I am fine with dropping any SDP negotiation on codec parameters including
> sampling rate and channels. I like the idea of splitting signaling and
> transportation issues.
>
>
>
> But one question remain. We had the question on limiting the complexity for
> some kind of devices by choosing a lower sampling rate or a low number of
> channels. Shall this negotiation be done with SDP or inband?
>
>
>
> Christian
>
>
>
>
>
> *Sent:* Wednesday, April 14, 2010 1:52 PM
> *To:* Roni Even

---

From: "Christian Hoene" <[email-masked]>
Date: Wed, 14 Apr 2010 14:37:22 +0200

Hi Stephen,
 
I am getting confused… Do you mean that the parameter about sampling rate MUST be negotiated with SDP and not transmitted in-band?
Or MUST NOT be negotiated inband but only transmitted inband?
Inband means within RTP/RTCP/RTPextentions and/or the Internet CODEC payload.
 
What do you think about my second question on sampling rate limits?
 
With best regards,
 Christian

 
From: stephen botzko [mailto:[email-masked]] 
Sent: Wednesday, April 14, 2010 2:25 PM
To: Christian Hoene
Cc: Roni Even; [email-masked]
Subject: Re: [codec] #8: Sample rates?
 
All negotiation should be done with SDP (and should never be done in-band)

And the RTP transport should be robust enough to permit seamless changes to any mode that is consistent with the negotiation (with
no signaling).  

The first point I think is essential.  The second reflects my own view on how RTP packetization should be done.

Stephen Botzko
On Wed, Apr 14, 2010 at 8:08 AM, Christian Hoene <[email-masked]> wrote:
Hi,

 
Christian

 

Stephen Botzko
 
Roni Even

Cc: [email-masked]
 
Hi ,
 
comments inline:

Stephen Botzko
True.

--Ben

---

From: stephen botzko <[email-masked]>
Date: Wed, 14 Apr 2010 09:55:32 -0400

In-band for me in this case means RTP only.  Or in some other contexts RTP
payload only.

I think there is
(a) negotiation - particularly defining what optional modes the receiver *
can* handle.  In the case of sample rates, number of channels, and any
optional facilities, this is generally not changing mid-call.  SDP is the
right place for this. (SDP SHALL be used for this)

(b) Feedback - messages related to QOS, packet loss, etc are what I mean by
this.  This should be done in RTCP, though given the lack of VOIP support
perhaps there should be a SIP INFO backup path.  Feedback should not be done
with RTP.

(c) Control - Per RFC 3551, RTCP can be used for "loosely controlled"
sessions, but "may be fully or partially subsumed by a separate session
control protocol".  Given the statements on RTCP support in the VOIP
infrastructure, we should be careful about putting unique controls in RTCP.
However, it should not be done in RTP.  Since most other audio codecs don't
require this stuff, I suspect we won't either.  Though we will see...

(d) In-band (RTP).  Not sure how else to say this.  Ideally RTP streams
carrying CODEC (with no out-of-band, no RTCP, no SDP parameter knowledge)
can be decoded.  That is, I think it should be possible to fully decode
unencrypted CODEC bitstreams with only the RTP packets abstracted from
Wireshark.  Even if the operating mode changes mid-flight.  RFC 5404 (G.719)
is one example of a packetization that accomplishes this, but there are
other packetization RFCs which do not.

Is this more clear?

Regards
Stephen Botzko

On Wed, Apr 14, 2010 at 8:37 AM, Christian Hoene <[email-masked]>wrote:

>  Hi Stephen,
>
>
>
> I am getting confused… Do you mean that the parameter about sampling rate
> MUST be negotiated with SDP and not transmitted in-band?
>
> *From**:* stephen botzko [mailto:[email-masked]]
> *Sent:* Wednesday, April 14, 2010 2:25 PM
> *To:* Christian Hoene
> *Cc:* Roni Even; [email-masked]
>

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Wed, 14 Apr 2010 17:25:33 +0200

You should replace "SDP" by "SDP Offer/Anser" (protocol), in order to emphasize the requirement for a) indication and possibly b) negotiation of codec configurations.
The number of potential parameters you are mentioning could result in a number of various codec configurations.
If this is the case, then the SDP O/A extensions would be recommended:
http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-sdp-media-capabilities/
which implies also support of
http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-sdp-capability-negotiation/
 
[Instead of RFC 3264 defined SDP Offer/Answer, which may be sufficient for a single codec configuration, but definetely insufficient in case of multiple codec configurations]

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of stephen botzko
	Sent: Mittwoch, 14. April 2010 15:56
	To: Christian Hoene
	Cc: [email-masked]
	Subject: Re: [codec] #8: Sample rates?

	In-band for me in this case means RTP only.  Or in some other contexts RTP payload only.
	
	I think there is 
	(a) negotiation - particularly defining what optional modes the receiver can handle.  In the case of sample rates, number of channels, and any optional facilities, this is generally not changing mid-call.  SDP is the right place for this. (SDP SHALL be used for this)
	
	(b) Feedback - messages related to QOS, packet loss, etc are what I mean by this.  This should be done in RTCP, though given the lack of VOIP support perhaps there should be a SIP INFO backup path.  Feedback should not be done with RTP.
	
	(c) Control - Per RFC 3551, RTCP can be used for "loosely controlled" sessions, but "may be fully or partially subsumed by a separate session control protocol".  Given the statements on RTCP support in the VOIP infrastructure, we should be careful about putting unique controls in RTCP.  However, it should not be done in RTP.  Since most other audio codecs don't require this stuff, I suspect we won't either.  Though we will see... 
	
	(d) In-band (RTP).  Not sure how else to say this.  Ideally RTP streams carrying CODEC (with no out-of-band, no RTCP, no SDP parameter knowledge) can be decoded.  That is, I think it should be possible to fully decode unencrypted CODEC bitstreams with only the RTP packets abstracted from Wireshark.  Even if the operating mode changes mid-flight.  RFC 5404 (G.719) is one example of a packetization that accomplishes this, but there are other packetization RFCs which do not.
	
	Is this more clear?
	
	Regards
	Stephen Botzko

	
	On Wed, Apr 14, 2010 at 8:37 AM, Christian Hoene <[email-masked]> wrote:

		Hi Stephen,

		I am getting confused... Do you mean that the parameter about sampling rate MUST be negotiated with SDP and not transmitted in-band?

		With best regards,

		 Christian

		Dr.-Ing. Christian Hoene

		Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532 
		http://www.net.uni-tuebingen.de/ <http://www.net.uni-tuebingen.de/> 

		 

		And the RTP transport should be robust enough to permit seamless changes to any mode that is consistent with the negotiation (with no signaling).  

		Stephen Botzko

		Hi,

		I am fine with dropping any SDP negotiation on codec parameters including sampling rate and channels. I like the idea of splitting signaling and transportation issues.

		But one question remain. We had the question on limiting the complexity for some kind of devices by choosing a lower sampling rate or a low number of channels. Shall this negotiation be done with SDP or inband?

		Christian

		Dr.-Ing. Christian Hoene

		Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532 
		http://www.net.uni-tuebingen.de/ <http://www.net.uni-tuebingen.de/> 

		
		Personally I favor carrying those H.264 parameter sets on the media path, since there are situations (switched multipoint calls for one) where the timing matters.  With that use case, if reliable-but-too-late delivery occurs, there are decoding errors even if there is no packet loss.  

		Stephen Botzko

		Hi,

		Negotiation of codec parameters is not a tradition it  is needed if there are optional modes that the decoder can support in order to allow the sender to know if the receiver can receive the specific mode. If there are mandatory modes you may be able to provide the information in-band but this is not negotiation. Also note that while the signaling may use reliable channel the media path is not reliable and may suffer packet loss that may cause the loss of important parameters. We have such example in the H.264 parameter sets where they can be carried in the SDP for reliability on in-band as part of the payload.

		Roni Even

		Cc: [email-masked]

		Hi ,

		comments inline:

		When I said signaling I meant SDP, not anything in the bitstream itself.  I was not excluding audio bandwidth changes mid-call as part of network adaptation.  Though as we all agree this needs to be carefully designed.
		
		I agree it is best if the decoder does not require any knowledge of the SDP negotiation (or any other information beyond the RTP packet stream itself) in order to correctly decode the audio -- which I think is what you were concerned about.

		CH: Negotiating codec parameters with SDP has a long tradition. Take for example µLaw (RTP payload type 0): Here you negotiate the sampling rate. Also, the number of channels are negotiated for many codecs. I think sampling rate and number of channels can be done with SDP. However, I would avoid other codec specific parameters. Especially, in case of AMR the negotiation is quite complex should be avoided for the Internet  CODEC.

		Christian
		
		It would be a nice property if reducing the acoustic bandwidth also allowed the MIPS to be reduced, but I do not think it is a requirement;  I'd personally rather manage complexity with a Low Complexity profile (if that is really needed), since then I could keep the acoustic bandwidth (accepting a higher bit rate instead).

		Stephen Botzko

		True.

		
		
		--Ben

---

From: "Christian Hoene" <[email-masked]>
Date: Fri, 16 Apr 2010 06:44:42 +0200

Hi all,

>It might be useful to state that it is not recommended to use 44100 Hz, because the conversion to
>16kHz and 32kHz is computational more demanding than 48kHz and requires more power/time.

Currently, proposed codec run at sampling rates of 

BroadVoice: 8, 16 kHz
SILK: 8, 12, 16, 24 kHz
CELT: 32 kHz to 96 kHz.

I do have a question. In order to make the RTP handling and the resampling simpler, it might be useful to skip the 44.1kHz compression mode. If only 8, 12, 16, 24, 32, and 48 kHz sampling rates are used, then the RTP timestamp can be easily counted in 96 kHz units. Supporting 44.1 kHz would require fractions of time stamp units that are difficult to handle with. Also, the resampling take more computational resource if it has to be done at high quality.

Thus, my question: Is 44.1 kHz really much-needed or can we use 32 or 48 kHz instead?

Christian

---

From: Koen Vos <[email-masked]>
Date: Thu, 15 Apr 2010 23:35:31 -0700

Quoting Christian Hoene:
> Supporting 44.1 kHz would require fractions of time stamp units

It would be better to base the RTP time stamp on a fixed sampling  
rate, independent of the sampling rates used at the API level and  
internally.  The reason is that the API and internal sampling rates  
may change at any time.  My proposal would be to count RTP time stamps  
at 48 kHz always.

>> It might be useful to state that it is not recommended to use 44100  
>> Hz because the conversion is computational more demanding

Not sure I see the need..  The CPU cost of resampling is negligible on  
many devices (certainly on PCs).  And if all other elements in the  
chain run at 44.1 kHz, then supporting it in the codec API could  
actually reduce the number of resamplers.

best,
koen.

> I do have a question. In order to make the RTP handling and the  
> resampling simpler, it might be useful to skip the 44.1kHz  
> compression mode. If only 8, 12, 16, 24, 32, and 48 kHz sampling  
> rates are used, then the RTP timestamp can be easily counted in 96  
> kHz units. Supporting 44.1 kHz would require fractions of time stamp  
> units that are difficult to handle with. Also, the resampling take  
> more computational resource if it has to be done at high quality.
>

---

From: "Christian Hoene" <[email-masked]>
Date: Fri, 16 Apr 2010 09:44:08 +0200

Hi Koen,

>may change at any time.  My proposal would be to count RTP time stamps

Using 48 kHz as RTP time stamp basis might be difficult for a 32 kHz internal sampling rate because you then might need to count 1,5
units of time. However, this might not be a problem if the frame size is a multiple of 3 or if we define a proper, bijective
rounding mechanisms for RTP time stamps.

In case of 44.1 kHz mapping to 48 kHz, a similar round function must be defined. 

Actually, some time ago I had a similar discussion regarding the support of multiple sampling rates in the draft-hoene-sbc.  The AVT
guys suggested me to either use the least common multiple of the sampling rates as RTP time stamp rate (which would be 96 kHz if
44.1 is not support), or to use different RTP payload types for different sampling rates.

A rounding function for RTP time stamps has not yet been defined in any RTP payload RFC. Thus, AVT guys might complain if we
introduce a rounding function. But then again, if it is well defined it should not be a technical problem...

Best,
 Christian

>>> Hz, because the conversion to

---

From: stephen botzko <[email-masked]>
Date: Fri, 16 Apr 2010 06:52:47 -0400

-Support of 48 kHz in sound cards, etc. is quite widespread, so personally I
see no requirement for 44.1 kHz (or 22.05, 11.025).

-RTP timestamp granularity of 96 kHz would be pretty hard to get through,
unless we actually have a 96 kHz mode of operation.  I don't see any
requirement for such a mode (though CELT happens to do it)

Might be worth summarizing where we are at this point:

-There appears to be a consensus that the RTP time base needs to remain
constant despite any changes to acoustic bandwidth. (due to network
adaptation)

- There is a consensus that frequent changes to acoustic bandwidth results
in a disturbing / unpleasant listening experience.

- There is consensus that it is ok to reduce the acoustic bandwidths at
lower bitrates,

- There is no consensus (as of yet) as to how many or which sampling rates
we need for the "internal codec", including no consensus that we need more
than one.  It is important to note that no one has *objected* to multiple
sample rates either. Though it has been observed that multiple sample rates
makes compressed domain mixing problematic.

Stephen Botzko

On Fri, Apr 16, 2010 at 12:44 AM, Christian Hoene <[email-masked]>wrote:

> because the conversion to
> I do have a question. In order to make the RTP handling and the resampling
> simpler, it might be useful to skip the 44.1kHz compression mode. If only 8,
> 12, 16, 24, 32, and 48 kHz sampling rates are used, then the RTP timestamp
> can be easily counted in 96 kHz units. Supporting 44.1 kHz would require
> fractions of time stamp units that are difficult to handle with. Also, the
> resampling take more computational resource if it has to be done at high
> quality.
>

---

From: stephen botzko <[email-masked]>
Date: Fri, 16 Apr 2010 06:58:06 -0400

One more, added in line---

On Fri, Apr 16, 2010 at 6:52 AM, stephen botzko <[email-masked]>wrote:

> -Support of 48 kHz in sound cards, etc. is quite widespread, so personally
> I see no requirement for 44.1 kHz (or 22.05, 11.025).
>

             *  - There is consensus that 48 kHz (fullband) operation is a
requirement.*

---

From: Brian West <[email-masked]>
Date: Fri, 16 Apr 2010 08:28:01 -0500

I agree these sampling rates shouldn't be a requirement.

/b

On Apr 16, 2010, at 5:52 AM, stephen botzko wrote:

> - I see no requirement for 44.1 kHz (or 22.05, 11.025).

---

From: Michael Knappe <[email-masked]>
Date: Fri, 16 Apr 2010 09:28:49 -0700

I agree as well, let's stick to the 48 kHz family and its common divisors.
Here's an interesting blurb on the origins of the 44.1 kHz sample rate and
its choice for the CD format.

http://www.cardinalpeak.com/blog/?p=150

Mike

---

From: "codec issue tracker" <[email-masked]>
Date: Wed, 21 Apr 2010 09:33:28 -0000

#8: Sample rates?
 Reporter:  hoene@…                 |       Owner:  jean-marc.valin@…             
Changes (by hoene@…):

  * owner:  => jean-marc.valin@…

Comment:

 KOEN wrote:

 CH: Number four is the RTP time stamp rate...

 On Fri, Apr 16, 2010 at 6:52 AM, stephen botzko <[email-masked]>
 wrote:
 -Support of 48 kHz in sound cards, etc. is quite widespread, so personally
 I see no requirement for 44.1 kHz (or 22.05, 11.025).
 CH: Many others agreed.

 -RTP timestamp granularity of 96 kHz would be pretty hard to get through,
 unless we actually have a 96 kHz mode of operation.  I don't see any
 requirement for such a mode (though CELT happens to do it).

 CH: Using 48 kHz as RTP time stamp basis might be difficult for a 32 kHz
 internal sampling rate because you then might need to count 1,5 units of
 time. ...  The AVT guys suggested me to either use the least common
 multiple of the sampling rates as RTP time stamp rate (which would be 96
 kHz if
 44.1 is not support), or to use different RTP payload types for different
 sampling rates.

 BOTZKO:

 - There is consensus that 48 kHz (fullband) operation is a requirement.

 - There is no consensus (as of yet) as to how many or which sampling rates
 we need for the "internal codec", including no consensus that we need more
 than one.  It is important to note that no one has objected to multiple
 sample rates either. Though it has been observed that multiple sample
 rates makes compressed domain mixing problematic.

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/codec/trac/ticket/8#comment:2>
codec <http://tools.ietf.org/codec/>