Re: [Discuss-gnuradio] how to implement synchronous source block correctly ?

[Marcus Müller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Artem,

On 04.12.2013 08:50, Artem Pisarenko wrote:
> 
> Martin Braun (CEL) wrote
>> You never use a throttle and a hardware clock in one flow graph
>> (e.g. throttle + audio)
> 
> Does it means that I can use multiple synchronous blocks of same
> type ?
Yes. GNU Radio is a buffered streaming architecture, so as long as the
production / consumption rates are equal on average, it should work.
If they vary over time or really differ, then you'll end up with
over/underruns

> Martin Braun (CEL) wrote
>> work() should never block. Sources are a bit of an exception,
>> though...
> 
> I see audio sink doesn't consume CPU, so it blocks too ? Another
> exception ?..
The GNU Radio Block idea (tm) is to have the scheduler call your work
as soon as there are samples available for processing and the blocks
downstream can take your block's output. Therefore, work()s should be
as fast as possible.

Obviously, sources don't have input, so the correct way to produce
limited samples over time is to take your time when producing samples.
So, for software sources (e.g. sine wave signal source), they just
produce as many samples as fast as they can, as the scheduler requests.

As for the audio source, the rate at which samples can be produced is
defined by hardware. So to produce e.g. 441 samples you need 10ms;
there's no way around that. So it *must* block for as long as it takes
to produce a reasonable / requested amount of samples for the output
buffer.

Throttle just throttles :) so you end up with backpressure that must
eventually lead to congestion which manifests in dropped samples,
stalled flowgraphs.
> 
> 
> Martin Braun (CEL) wrote
>> - I'm pretty sure you've misunderstood the concept of a "sync
>> block". Refer to [1] for an introduction. It merely describes the
>> ratio of input and output rates. The opposite of a sync block is
>> *not* an 'async' block.
> 
> No, it's just ambiguous terminology. How should we call blocks
> producing output synchronously with some reference source ?
I'd like to disagree. GR talks about "sync" blocks, and since it's a
pure software framework, it's obvious that the synchronous aspect is
in respect to sample flow, not to time.
Remember: there is no real realtime in general purpose signal
processing with GR.

you could say, your block is time-synchronous, but seriously, since
you always fill a buffer, this is not really true; I'd call it "rate
limited by hardware".

> Martin Braun (CEL) wrote
>> - The scheduler does all the work for you regarding calling of
>> work(). You don't need to interrupt work(). Not sure what you're
>> intentions were with using stop().
> 
> My intention was to use non-timeout blocking calls (as supposed to
> be correct) in work() with wait condition on some "stop" signal.
ah ok. But: stop() stops the flowgraph.

Greetings, and happy hacking!

Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSnu2kAAoJEAFxB7BbsDrLCvAH/ju+5l2oGU8KfB3zO+Neb8Od
nLmcb8CC0elmIF25OaB6xvWayZZp7MkQk7ulfvbIZlkE0sG6/Fdra/bPqzL519Nu
3wj6gyLA2Lrg0YpInO+zP3PIT25QPjORLvOSO4APFKFfdZMTCNbltdV5SNWiue/4
0e6Kjo7+6VZDYPkeZn2NzpKf/AcUzpnHFaM4Viz/UIjBGfDBpFCTCGFiMyC9QRgd
QxCRIm0a20Wk2O0PlyJ+e7OE1JCiFsjUjQp9QhoMcyfIxESI5sNvBamSB14+tNri
eitR2s+ExzgDRNrf7datCue2rEZ6ISQounsujjqVbVw5gPluQ+n17rXliddmGTc=
=wfRp
-----END PGP SIGNATURE-----