[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 20:04:53 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Oct 25, 2016 at 09:07:57PM +0200, Marcus Müller wrote:

> So, yeah, again, two-clock problem:
> If your red pitaya samples at, let's say, 4.8 MHz, and your sound card
> samples at 48kHz, then you need to decimate by a factor of hundred.
> Problem is that the sampling rate of the Sound card is never actually
> exactly 1/100 of the redpitaya rate – no two oscillators on this earth
> are exactly the same. With the red pitaya vs sound card, it should be a
> little more benign than CPU time vs sound card, because I'd expect both
> the red pitaya and your sound card to have "relatively good
> oscillators", ie. a total offset of <50ppm, i.e. one of them is slower
> than the other, but it takes 50 million samples until one is 1 sample
> "late". For things that have megasample-per-second rates, that might
> happen rather quickly.

With 50 ppm it takes only 20e3 samples. And consumer grade audio cards
can have much higher clock rate errors, up to 0.1%.

> > So is the solution for such problems a tagged stream with control through
> > tags or the usage of PDUs?

> To combat this, you'd either need to somehow link the two sampling rates
> (e.g. use the pitaya's oscillator to drive your self-built soundcard),
> you need to have infinitely large buffers, or some control loop that,
> based on some observation such as buffer fillage, estimates and corrects
> the rate offset.
> There's no "ready to use" solution for this problem.

At least on Linux there are two programs (of which I'm the author) that
actually solve this, by adaptive resampling. One allows to use more than
one (unsynchronised) sound card with Jack, the other adapts audio data
from a network stream to the local sample rate. This can be done without
any loss of quality. CPU load on a modern system is almost nothing.

Normally I'd be more than happy to contribute a solution to gnuradio.
By 'normally' I mean if someone had taken the trouble to reply to
my simple question about the Jack audio interface posted a few weeks
ago. Nobody seems to care that it doesn't work, so I'm not going
to waste my time.



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]