Arbitrary asynchronous (plesiochronous?) resampling in "real time"

Hello all,

I have two audio devices which differ slightly in sample rate (i.e. 8000
Hz and 7999 Hz).

I would like to have those streams in the same sample rate, and the
maximum tolerable delay is about 5-10 ms. Which methods exist, and where
can I find some good documentation about this? The solution is to be
implemented on a regular PC.

Grateful for any pointers,
		
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com

snappy wrote:
> Hello all,
>
> I have two audio devices which differ slightly in sample rate (i.e.
8000
> Hz and 7999 Hz).
>
> I would like to have those streams in the same sample rate, and the
> maximum tolerable delay is about 5-10 ms. Which methods exist, and
where
> can I find some good documentation about this? The solution is to be
> implemented on a regular PC.
>
> Grateful for any pointers,

I'd play the sequences "as is" and either skip one sample in the
longer stream or repeat one sample in the shorter stream, every
second.

But of then, you might not have exact knowledge of how much out
of sync your streams are at any one time, in which case it could
be awkward to find synchronization points...

Rune

>I'd play the sequences "as is" and either skip one sample in the
>longer stream or repeat one sample in the shorter stream, every
>second.
>
>But of then, you might not have exact knowledge of how much out
>of sync your streams are at any one time, in which case it could
>be awkward to find synchronization points...

The problem with the skip/repeat method is that is it very audible. I do
not want the resampling to be noticed at all.

I have seen some posts about linear interpolation filters that seem to
filter the entire stream to the 'correct' rate. It seems like it is this
continous method that is the only way not to introduce clicks or pops. Can
you do this interpolation and at the same time keep the delay at 10 ms?

Thanks

		
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com

snappy wrote:
> 
> Hello all,
> 
> I have two audio devices which differ slightly in sample rate (i.e. 8000
> Hz and 7999 Hz).
> 
> I would like to have those streams in the same sample rate, and the
> maximum tolerable delay is about 5-10 ms. Which methods exist, and where
> can I find some good documentation about this? The solution is to be
> implemented on a regular PC.

You might want to try Secret Rabbit Code:

    http://www.mega-nerd.com/SRC/

The transport delay is probably on the border of what you can accept.

SRC is capably of time varying sample rate conversion so should be able
to track the differences.

> This message was sent using the Comp.DSP web interface on
> www.DSPRelated.com

You should probably get a real Usenet account rather than using that
web interface.

Erik
-- 
+-----------------------------------------------------------+
  Erik de Castro Lopo  nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"There is no satisfactory substitute for excellence."
-- Dr. Arnold O. Beckman

in article k_KdncqrSMHXBfHfRVn-3w@giganews.com, snappy at glad@kth.se wrote
on 04/25/2005 03:12:

> I have two audio devices which differ slightly in sample rate (i.e. 8000
> Hz and 7999 Hz).
> 
> I would like to have those streams in the same sample rate, and the
> maximum tolerable delay is about 5-10 ms. Which methods exist, and where
> can I find some good documentation about this? The solution is to be
> implemented on a regular PC.

this is a real-time streaming device?  how does your PC know about the clock
times of both devices?

asynchronous SRC is something that happens (check out the original chips,
the Analog Devices AD1890 series), but i don't see how you can do it with
your PC unless you have hardware that detects the clock pulses and a high
speed clock so you can measure the time between pulses.

-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

> >I'd play the sequences "as is" and either skip one sample in the
> >longer stream or repeat one sample in the shorter stream, every
> >second.
> >
> >But of then, you might not have exact knowledge of how much out
> >of sync your streams are at any one time, in which case it could
> >be awkward to find synchronization points...
>
> The problem with the skip/repeat method is that is it very audible. I do
> not want the resampling to be noticed at all.
>
> I have seen some posts about linear interpolation filters that seem to
> filter the entire stream to the 'correct' rate. It seems like it is this
> continous method that is the only way not to introduce clicks or pops.

Yes, you will need to filter the entire stream so as not to introduce clicks and
pops.  Linear interpolation is one way (in fact the simplest way) to do this,
but there are are many other ways to interpolate as well.  Other methods allow
you to achieve better quality at the expense of more computation.

> Can you do this interpolation and at the same time keep the delay at 10 ms?

Well, that all depends on your platform (PC/soundcard/OS, custom hardware, etc.)
and what delays it adds. What are you working with?  The raw linear
interpolation filter itself would introduces a delay of at most 1 sample, which
at 8kHz is only 0.125 ms.  But in a typical system, the total delay is dominated
by things such as the ADC and DAC delays, buffering requirements of the
processing hardware/software, etc..  If your total hardware delay for a "talk
through" (take in an input, output it again unmodified) is less that 10 ms, you
should be OK.

In article <116q9b3ilte9hfe@corp.supernews.com>,
Jon Harris <jon_harrisTIGER@hotmail.com> wrote:
>> >I'd play the sequences "as is" and either skip one sample in the
>> >longer stream or repeat one sample in the shorter stream, every
>> >second.
>> >
>> >But of then, you might not have exact knowledge of how much out
>> >of sync your streams are at any one time, in which case it could
>> >be awkward to find synchronization points...
>>
>> The problem with the skip/repeat method is that is it very audible. I do
>> not want the resampling to be noticed at all.
>>
>> I have seen some posts about linear interpolation filters that seem to
>> filter the entire stream to the 'correct' rate. It seems like it is this
>> continous method that is the only way not to introduce clicks or pops.
>
>Yes, you will need to filter the entire stream so as not to introduce clicks
>and
>pops.  Linear interpolation is one way (in fact the simplest way) to do this,

Linear interpolation will sound awful.  Use windowed-Sync interpolation
with a precalculated sin/cos table.  At 8 Khz you can use up to 15 taps
and still have a delay of under a millisecond (plus the sound card FIFO
delay).


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

>this is a real-time streaming device?  how does your PC know about the
clock
>times of both devices?
>
>asynchronous SRC is something that happens (check out the original
chips,
>the Analog Devices AD1890 series), but i don't see how you can do it
with
>your PC unless you have hardware that detects the clock pulses and a
high
>speed clock so you can measure the time between pulses.

Yes it is. The clock rates are unknown, but the drift can be measured
"off-line" by playing out impulses and looking at the difference in delay
after a certain number of samples. This is okay for now.

I've checked the AD1890 tech sheet. Looks nice, I'll try to implement that
interpolation scheme.

Someone wrote about windowed sinc interpolation. Is this the way to go to
get rid of strange endpoint values in the individual buffers?

Thanks
		
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com

in article d4n1ku$5dp$1@blue.rahul.net, Ronald H. Nicholson Jr. at
rhn@mauve.rahul.net wrote on 04/26/2005 23:41:

> Linear interpolation will sound awful.  Use windowed-Sync interpolation
> with a precalculated sin/cos table.  At 8 Khz you can use up to 15 taps
> and still have a delay of under a millisecond (plus the sound card FIFO
> delay).

true, but the OP has another problem which is the asynchronous nature.
without getting *both* input and output clocks (as well as the input
samples), i can't see how he can do this thing.  somehow, he has to derive
the sample rate ratio (which can drift a little in an async application).
how's he gonna do that without the clocks?

-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."

"robert bristow-johnson" <rbj@audioimagination.com> wrote in message
news:BE952FF5.6A5B%rbj@audioimagination.com...
> in article d4n1ku$5dp$1@blue.rahul.net, Ronald H. Nicholson Jr. at
> rhn@mauve.rahul.net wrote on 04/26/2005 23:41:
>
> > Linear interpolation will sound awful.  Use windowed-Sync interpolation
> > with a precalculated sin/cos table.  At 8 Khz you can use up to 15 taps
> > and still have a delay of under a millisecond (plus the sound card FIFO
> > delay).
>
> true, but the OP has another problem which is the asynchronous nature.
> without getting *both* input and output clocks (as well as the input
> samples), i can't see how he can do this thing.  somehow, he has to derive
> the sample rate ratio (which can drift a little in an async application).
> how's he gonna do that without the clocks?

Assuming you have some sort of an input FIFO/buffer, I'm thinking you could
monitor the buffer empty/full status and adjust the output sample rate to
maintain a nearly constant level, slowing down if it's nearly empty and speeding
up if it's nearly full.  It will probably end up looking like some sort of
digital PLL algorithm.  It's not trivial, but should be possible unless I'm
missing something.