[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] simple mod-demod combinations doesn't work

From: Fons Adriaensen
Subject: Re: [Discuss-gnuradio] simple mod-demod combinations doesn't work
Date: Tue, 25 Oct 2016 21:21:17 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

Hi Marcus,

> sorry, please believe me, no-one meant to upset you. I'm a bit surprised
> you're taking this so personally!

I'm pretty sure nobody wanted to upset me ! But apparently nobody is
interested to make the Jack interface work as intended, not even its

> Anyway, how do you estimate the sample rate offset? Buffer fillage
> derivative? As you said, the problem is not lacking a resampler (in
> fact, the GNU Radio PFB resamplers are almost too good for this), or the
> CPU to run it, but to know what your sound cards are doing...

See <http://kokkinizita.linuxaudio.org/papers/adapt-resamp-pres.pdf>
and <http://kokkinizita.linuxaudio.org/papers/adapt-resamp.pdf>

Between the two incoherent domains there is a buffer and a resampler.
The resampler is adjusted so that the average number of samples 'in
the pipeline' is constant. The problem is finding a reliable and
noise-free estimate of that number. At both ends we don't have a
clean continuous stream, but samples are written and read in blocks,
and the timing of those write and read operations can be irregular.
The solution is to have a delay-locked-loop (DLL) at either side
to remove measured timing jitter. This provides a continuous mapping
of time to the number of samples written and read. The difference
between the two is average number of samples in the buffer, which
is compared to a target value. The filtered difference then controls
the resampling ratio.



A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]