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

[Marcus Müller]

Hi Fons,

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

This is Free Software - since none of us felt confident in their Jack
skills, I guess no-one answered, and we can't blame you for not
contributing your time, but, of course, we still hope you'll do – it's
what we do ourselves, after all. (also, in less happy news: as far as I
know, it's not a known problem or even something that we'd have a
workaround ready for. There might simply not be that many Jack + GNU
Radio users :( )

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...

Best regards,
Marcus


On 25.10.2016 22:04, Fons Adriaensen wrote:
> 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.
>
> Ciao,
>