Hi

Not totally updated on this issue but the AMR speech codec family can adjust the codec rate over a 
relatively large range. 
AMR-NB (0-4kHz audio spectum) has the bitrate range 4.75 to 12.2kbps
AMR-WB (0-8kHz audio spectum) has the bitrate range 6.60 to 23.85kbps
C-code is available at 
http://www.3gpp.org/ftp/Specs/html-info/26104.htm
http://www.3gpp.org/ftp/Specs/html-info/26173.htm
Payload format is described in RFC3267

Also is available an audio codec (AMR-WB+) with bitrate range 5.2-48kbps at
http://www.3gpp.org/ftp/Specs/html-info/26304.htm
Payload format is described in RFC4352 

Regards
Ingemar

> -----Original Message-----
> From: Lars Eggert [mailto:lars.eggert@netlab.nec.de] 
> Sent: den 12 september 2006 09:27
> To: Arne Lie
> Cc: dccp@ietf.org
> Subject: Re: SV: [dccp] DCCP voice quality experiments
> 
> Hi, Arne,
> 
> On Sep 11, 2006, at 11:01, Arne Lie wrote:
> > 1. What I find difficult to understand is if your applications have 
> > any native rate adaptation, except packet drops at sender when the 
> > sender buffer (of 5 packets?) have been saturated.
> 
> the codecs we used don't change their rate in the presence of 
> losses, no matter where they occur (send buffer or along the path.
> 
> > Is it so that *if* (and when) TFRC
> > gives you an equivalent rate below G.711 rate of 95.2kbps, 
> or 39.2kbps 
> > for G.729, your sender WILL drop packets when using TFRC (any 
> > variant), while the UDP system will hand the problem over to the 
> > network routers?
> 
> TFRC can cap the send rate at the sender, which UDP doesn't.
> 
> > I.e., my
> > main question is if G.711 and G.729 have any methods for 
> lowering the 
> > codec rate output below 64 and 8kbps, respectively (by 
> quantiser scale 
> > change, or any other means)
> 
> No, see above. Tom has a draft on how codecs that adapt their 
> rate may interact with DCCP.
> 
> > 2. You have an experimental set-up. Why do you not also set-up real 
> > receivers (players) so that the perceptual quality can be 
> evaluated, 
> > instead of, or in addition to, your "E-model R-score"
> 
> You mean use PESQ as a metric instead of the E-model? We 
> could have done that, but most related work has used the 
> E-model and we wanted to more directly compare our results to 
> theirs. Also, it would have required additional work and we 
> were not sure that we'd get significantly more precise 
> results this way.
> 
> > 3. You use DummyNet to insert packet loss and delay. Are you 
> > considering experimenting without DummyNet, but instead inject more 
> > real traffic to create real router congestion? I think that 
> will give 
> > you a more natural environment in which you can test TFRC 
> performance 
> > under more realistic scenarios.
> 
> Yes, definitely. In this first evaluation, however, we wanted 
> to be able to very tightly control the environment, in order 
> to be able to analyze the behavior we were seeing.
> 
> We did run additional tests with multiple competing flows up 
> to and past the point of congestion, to investigate the 
> relative fairness of the different TFRC flavors, but these 
> aren't in the current paper.
> 
> Lars
> -- 
> Lars Eggert                                     NEC Network 
> Laboratories
> 
>