FPGA Central

Hello,

I have a discussion with my collegue regarding sample rate conversion.

The scenario is this, we have an input nominally at 48kHz and an
output at the same frequency, 48kHz. These have different clock
sources and there is a risk of clock drift between the input and
output. My collegue tells me we need "sample rate conversion" to cope
with this, with two inputs:

1. an estimate of input clock frequency
2. an estimate of output clock frequency

and do sample rate conversion with these figures at hand.

I have a traditional view upon sample rate conversion as a means of
establishing conversion by a rational factor, D/M, incorporating zero
stuffing, maybe polyphase intermediate LP-filtering, and throwing away
samples as a last step. If the clock sources differs by by a fraction
of maybe 1/1000, I see no other alternative than 48001/48000 as (D/M)
and, at first sight, the traditional sample rate conversion approach
seems not so suited for this case.

I thought the ideal 1<->1 cases where handled by a buffering procedure
and the occasional inserting, or discarding, of samples.

Morgan

Sounds as though you want a 'slip buffer' I agree , maybe your colleagues
know it better as plesiochronous conversion?
Mike

"Morgan P?lsson" <[email protected]> wrote in message
news:[email protected] om...
> Hello,
>
> I have a discussion with my collegue regarding sample rate conversion.
>
> The scenario is this, we have an input nominally at 48kHz and an
> output at the same frequency, 48kHz. These have different clock
> sources and there is a risk of clock drift between the input and
> output. My collegue tells me we need "sample rate conversion" to cope
> with this, with two inputs:
>
> 1. an estimate of input clock frequency
> 2. an estimate of output clock frequency
>
> and do sample rate conversion with these figures at hand.
>
> I have a traditional view upon sample rate conversion as a means of
> establishing conversion by a rational factor, D/M, incorporating zero
> stuffing, maybe polyphase intermediate LP-filtering, and throwing away
> samples as a last step. If the clock sources differs by by a fraction
> of maybe 1/1000, I see no other alternative than 48001/48000 as (D/M)
> and, at first sight, the traditional sample rate conversion approach
> seems not so suited for this case.
>
> I thought the ideal 1<->1 cases where handled by a buffering procedure
> and the occasional inserting, or discarding, of samples.
>
> Morgan

In article <[email protected] >,
Morgan P?lsson <[email protected]> wrote:
>I have a discussion with my collegue regarding sample rate conversion.
>
>The scenario is this, we have an input nominally at 48kHz and an
>output at the same frequency, 48kHz. These have different clock
>sources and there is a risk of clock drift between the input and
>output. My collegue tells me we need "sample rate conversion" to cope
>with this, with two inputs:
>
>1. an estimate of input clock frequency
>2. an estimate of output clock frequency
>
>and do sample rate conversion with these figures at hand.
>
>I have a traditional view upon sample rate conversion as a means of
>establishing conversion by a rational factor, D/M, incorporating zero
>stuffing, maybe polyphase intermediate LP-filtering, and throwing away
>samples as a last step. If the clock sources differs by by a fraction
>of maybe 1/1000, I see no other alternative than 48001/48000 as (D/M)
>and, at first sight, the traditional sample rate conversion approach
>seems not so suited for this case.

You can handle arbitrary and varying phase differences by windowed-Sinc
interpolation. On a fast PC you can actually calculate the exact
coefficients (cos, sin and recip) for each sample on the fly in realtime.
On slower DSP's, an interpolated table lookup may be more appropriate.


IMHO. YMMV.
--
Ron Nicholson rhn AT nicholson DOT com http://www.nicholson.com/rhn/
#include <canonical.disclaimer> // only my own opinions, etc.

On 25 Jun 2004 02:52:00 -0700, [email protected] (Morgan
P?lsson) wrote:

>Hello,
>
>I have a discussion with my collegue regarding sample rate conversion.
>
>The scenario is this, we have an input nominally at 48kHz and an
>output at the same frequency, 48kHz. These have different clock
>sources and there is a risk of clock drift between the input and
>output. My collegue tells me we need "sample rate conversion" to cope
>with this, with two inputs:
>
>1. an estimate of input clock frequency
>2. an estimate of output clock frequency
>
>and do sample rate conversion with these figures at hand.
>
>I have a traditional view upon sample rate conversion as a means of
>establishing conversion by a rational factor, D/M, incorporating zero
>stuffing, maybe polyphase intermediate LP-filtering, and throwing away
>samples as a last step. If the clock sources differs by by a fraction
>of maybe 1/1000, I see no other alternative than 48001/48000 as (D/M)
>and, at first sight, the traditional sample rate conversion approach
>seems not so suited for this case.

ISTR there are several algorithms for doing this, though I'm not
familiar with them. I just looked, and as I suspected there are
single-chip solutions from ti.com and analog.com (put sample rate
converter in the search texbox at each site). You may want to get the
data sheets/app notes for those and see how much detail they give
about the algorithm(s) used.
If you want to learn more about it, try a websearch on the keywords
used in the data sheets. If you just need to do such a conversion,
just use one of these chips. I read a little about them a few years
ago, and they're supposedly the best solution available. Allegedly
they work just like a D/A->A/D conversion, but have much better
quality.

>I thought the ideal 1<->1 cases where handled by a buffering procedure
>and the occasional inserting, or discarding, of samples.

I don't think you want to do that in any case.

>Morgan

"Morgan P?lsson" <[email protected]> wrote in message
news:[email protected] om...
>
> The scenario is this, we have an input nominally at 48kHz and an
> output at the same frequency, 48kHz. These have different clock
> sources and there is a risk of clock drift between the input and
> output. My collegue tells me we need "sample rate conversion" to cope
> with this, with two inputs:
>
> 1. an estimate of input clock frequency
> 2. an estimate of output clock frequency
>
> and do sample rate conversion with these figures at hand.

Sounds right to me.

> I have a traditional view upon sample rate conversion as a means of
> establishing conversion by a rational factor, D/M, incorporating zero
> stuffing, maybe polyphase intermediate LP-filtering, and throwing away
> samples as a last step. If the clock sources differs by by a fraction
> of maybe 1/1000, I see no other alternative than 48001/48000 as (D/M)
> and, at first sight, the traditional sample rate conversion approach
> seems not so suited for this case.

Polyphase SRC can be used for any ratio, but larger ratios require larger tables
of coefficients. Usually, you can find a compromise between the table size and
granularity of possible frequencies. Your algorithm may have to "dither" back
and forth between 2 adjacent ratios to exactly match the required ratio. (For
example, in a crude system if you could only perform SRC changes by a factor of
1.1 or 1.2 and you needed 1.15, you would alternate between these two.) Another
possibility is to use simple linear interpolation of coefficients between the
table entries. This generally works quite well to reduce table size if memory
is limited. Some of the dedicated SRC chips do in fact use this technique to
get extremely fine resolution with limited ROM space. Or, as Ron Nicholson
suggested, you can calculate the filter coefs on the fly for any ratio if you
have the processing power.

> I thought the ideal 1<->1 cases where handled by a buffering procedure
> and the occasional inserting, or discarding, of samples.

Certainly some digital audio systems use this technique. For example, sending
an unsynced AES signal to a digital recorder will usually work like this.
However, this may not be satisfactory for some applications. The "beating" of
the 2 sample frequencies will produce a periodic discontinuity that may sound
like a click. Depending on your audio material and the rate of clicking, this
may be totally unacceptable or essentially unnoticeable.

On Mon, 28 Jun 2004 11:29:43 -0700, "Jon Harris"
<[email protected]> wrote:

>> I thought the ideal 1<->1 cases where handled by a buffering procedure
>> and the occasional inserting, or discarding, of samples.
>
>Certainly some digital audio systems use this technique.

The PSTN is perhaps the prime example. They put strict limits on the
differences in the master clocks to limit the rate of slips. This
only happens at boundaries between networks (e.g. international
boundaries).

Regards,
Allan.

"Allan Herriman" <[email protected]> wrote in
message news:[email protected]..
> On Mon, 28 Jun 2004 11:29:43 -0700, "Jon Harris"
> <[email protected]> wrote:
>
> >> I thought the ideal 1<->1 cases where handled by a buffering procedure
> >> and the occasional inserting, or discarding, of samples.
> >
> >Certainly some digital audio systems use this technique.
>
> The PSTN is perhaps the prime example. They put strict limits on the
> differences in the master clocks to limit the rate of slips. This
> only happens at boundaries between networks (e.g. international
> boundaries).

Interesting. For those (like me) who aren't familiar with the acronym PSTN,
here is a definition:

PSTN (public switched telephone network) is the world's collection of
interconnected voice-oriented public telephone networks, both commercial and
government-owned. It's also referred to as the Plain Old Telephone Service
(POTS). It's the aggregation of circuit-switching telephone networks that has
evolved from the days of Alexander Graham Bell ("Doctor Watson, come here!").
Today, it is almost entirely digital in technology except for the final link
from the central (local) telephone office to the user.

Jon Harris wrote:

> "Allan Herriman" <[email protected]> wrote in
> message news:[email protected]..
>
>>On Mon, 28 Jun 2004 11:29:43 -0700, "Jon Harris"
>><goldentully@ho[email protected]> wrote:
>>
>>
>>>>I thought the ideal 1<->1 cases where handled by a buffering procedure
>>>>and the occasional inserting, or discarding, of samples.
>>>
>>>Certainly some digital audio systems use this technique.
>>
>>The PSTN is perhaps the prime example. They put strict limits on the
>>differences in the master clocks to limit the rate of slips. This
>>only happens at boundaries between networks (e.g. international
>>boundaries).
>
>
> Interesting. For those (like me) who aren't familiar with the acronym PSTN,
> here is a definition:
>
> PSTN (public switched telephone network) is the world's collection of
> interconnected voice-oriented public telephone networks, both commercial and
> government-owned. It's also referred to as the Plain Old Telephone Service
> (POTS). It's the aggregation of circuit-switching telephone networks that has
> evolved from the days of Alexander Graham Bell ("Doctor Watson, come here!").
> Today, it is almost entirely digital in technology except for the final link
> from the central (local) telephone office to the user.
>
>
Actually PTSN and POTS refer to two different things. If you live in
the states and get your phone service on a single twisted pair with a
-48V bias to power your phone then you're on a POTS line. You can also
connect to the PTSN via T1 (if you have multiple lines and the right
equipment), or you can connect via ISDN (Integrated Services Digital
Network, AKA "It Still Does Nothing"). I believe that the French have
all converted to ISDN, but I don't know if both acronyms apply there.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com