Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>: sampling rate

[Randell Jesup <rjesup at wgate.com>]

Colin Perkins <csp at csperkins.org> writes:
>> The fact that VMR-WB is capable of processing narrowband (8 kHz) or
>> wideband (16 kHz) media does not have anything to do with its internal
>> sampling frequency.
>
>Exactly. This is why the RTP timestamp rate should be either 8kHz or 16kHz,
>depending on the input source.

        Well, this (having the RTP timestamp rate be the sampling
frequency) isn't the case for a number of non-audio RTP streams (such as
video streams, which typically use 90000 regardless of pixel, line, or
frame rate), so there's precedent for a "fixed" timestamp rate.

        There's no reason all the audio codecs couldn't have used
any value (even 90000); it's convention that it be the sampling rate.
It avoids a multiply/divide to convert a timestamp into a sample-time,
and there's no error involved (which there would be if sample and
timestamps didn't convert cleanly), but that's about it.

        Having timestamp rate be sampling rate can allow implicit
determination of the packetization-interval, but that should be provided
separately anyways.  This implicit packetization-interval only adds
something if the packetization-interval is non-static within a session (and
most if not all audio codecs disallow that excluding silence-supression).


        Not that such things exist currently, but playing devil's advocate,
one could create a codec that takes a variable-sampling-rate input
depending on current conditions.  (Similar to video codecs that vary the
frame rate, resolution, and/or bitrate within a stream.)

        The important thing about timestamps is that they provide
*enough* resolution to accurately know when to play the date contained
within.  For example, for professional audio work, one might have a real
need for an N-times multiple of the sample rate.  The reason is that
sample rate defines the bandwidth of the signal, but the timing of the
signal required might be tighter, such as if it needs to be mixed with
other streams (especially other higher-bandwidth streams).  Back in the
Amiga video days we had a ~1400x480i video mode, even though NTSC
monitors were lucky to show anything approaching 640.  The reason was
that fine control of where a signal started (such as the curve of a
'C') produced better, smoother diagonals and curves.  (anti-aliasing of
a sort, if you like.)


        While I don't see a _need_ for a multi-rate audio codec to use
a fixed timestamp rate, I also don't see a _need_ for the timestamp rate
to be the sample rate for audio, other than tradition.  Perhaps I'm
missing something.

-- 
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team
rjesup at wgate.com


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt