Re: [codec] #8: Sample rates?

[stephen botzko <[e-mail]>]

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 <[e-mail]>wrote:

> >
> >#8: Sample rates?
>
> >------------------------------------+---------------------------------------
> > Reporter:  hoene@…                 |       Owner:
> >     Type:  enhancement             |      Status:  new
> > Priority:  minor                   |   Milestone:
> >Component:  requirements            |     Version:
> > Severity:  Active WG Document      |    Keywords:
>
> >------------------------------------+---------------------------------------
> >
> >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.
>
> 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
>
>
>
>
>
>
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec
>