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

[Marcus Müller]

Hi Markus,

> The only blocking element is the [audio sink] in "blocking mode" (of
> course).
yep. It can only consume as fast as the sound hardware consumes audio
samples.
> If i start an audio flow graph without [throttle] and increase some additive
> noise or change the volume with a multiplier in the stream the audible
> signal gets effected way too slow (action-to-effect-time approximately 10 s
> or more).
That's the effect of having overly large buffers between the blocks.
These buffers run full if there's a bottleneck (in this case, the audio
sink)
>  If I use a [throttle] after the [wav file source] i can effect the
> stream directly - maybe i can call it "in real time", but then sometimes aU
> occurs.
"Real Time" has a different definition in the context of DSP, but yes,
due to the throttle, the buffers don't fill – instead, they run empty,
and then you get the aU. You can't have the aU, and thus, you must
**never** use throttle with an audio sink. Simple as that, no exceptions.

> The issue remains also if i use real hardware (redpitaya with osmocom
> blocks) an resampler blocks in the stream.
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.
> So is the solution for such problems a tagged stream with control through
> tags or the usage of PDUs?
first of all: rule out that you misconfigured the pitaya or your sound
card. make sure both devices actually support the sampling rate you ask
them to do (and don't automatically choose a different one), and your
decimation ratio reflects the ratio between these sampling rates.

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.

Best regards,
Marcus