Re: [codec] #8: Sample rates? 44.1kHz?

Hi Koen,

>> 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.

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

>
>best,
>koen.
>
>
>
>> 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
>>
>>
>> _______________________________________________
>> codec mailing list
>> codec@ietf.org
>> https://www.ietf.org/mailman/listinfo/codec
>>