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

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.

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