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

[Martin Braun (CEL)]

On Tue, Dec 03, 2013 at 11:50:44PM -0800, Artem Pisarenko wrote:
> Martin Braun (CEL) wrote
> > There's an overview of the scheduler:
> > http://gnuradio.squarespace.com/blog/2013/9/15/explaining-the-gnu-radio-scheduler.html
> > "Users", as you say, usually don't need more than this to write GNU
> > Radio code, and most often don't need to know anything at all about it.
> 
> If I'm not user, but also I'm not developer, who am I then ? ;)
> I reviewed this "developers-internal" document already and that's why I
> intentionally mentioned user point of view.

In GNU Radio terminology, since we're more of a library than an
application, users are people who use GNU Radio to develop their own
applications. Developers are people who actively work on GNU Radio and
improve it.

It's the same with other libraries. Do you use Boost or are you
developing Boost? Obviously, I don't know what you do outside this list,
but chances are you use it. Still, the only thing you'll be using it for
is developing.

> 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 ? I've
> checked "audio source -> audio sink" and I get same underruns.

You still have two clocks in one flow graph. Underruns can still happen.
You may use as many gr::sync_blocks in one flow graph as you wish. They
have nothing to do with clocks.

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

It *can* block, depending on the backend, but doesn't have to.
Note that not consuming CPU is not necessarily due to blocking. An audio
sink is quite a simple matter, from a signal processing point of view:
Incoming samples are passed on to the sound driver, then the work
function can immediately return (there's lots of status checking in
there too).

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

We call them 'source block'. The fact that some hardware clock is
somewhere in that block is irrelevant, all GNU Radio blocks are driven
by the states of their buffers.

MB


> 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.
> 
> 
> Martin Braun (CEL) wrote
> > Writing blocks is one of the things we try and document as good as
> > possible. The corresponding tutorial [1] has received a lot of feedback
> > and has been continuously updated. It also discusses most of the
> > questions you had earlier.
> 
> Due to lack of documentation, this tutorial was the only source and I
> learned it from cover to cover. I mentioned only non-trivial issues which is
> not discussed in it. So it's new feedback ;)

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

pgpl8QYhm8mAt.pgp
Description: PGP signature