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

[Marcus Müller]

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

Hi again!

On 04.12.2013 11:36, Artem Pisarenko wrote:
> 
>> 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.
>> 
> I meant user/developer from toolkit use point of view: user -
> developer who uses GNU Radio API in its applications and have no
> time/budget to delve into innards of huge ready-to-use code only to
> know few key concepts, developer - developer of GNU Radio toolkit.
Well, unfortunately, this is open source :) some things are easier to
do while others take a lot of time. Explaining how something works
internally for someone who is actually interested in that but doesn't
have the time to read the source itself is among the things that are
hard to do well, become obsolete fast, take a lot of time -- so nobody
does it.
>> You still have two clocks in one flow graph. Underruns can still
>> happen.
> 
> Why ??? These clocks are actualy same clock. They are synchronous.
No. Well, yes. But no.
Again, there is no continous stream in GNU Radio. Samples and
especially blocks of samples, as used in GR, are not like water: They
flow in chunks, there are buffers to accumulate them.
Usually, these buffers should be automatically sized so that two
sources with the same, constant sample production rate never run out
of buffer. I don't know what's going wrong in your case, but that
could happen if the sample delay for one of the sources differs from
the others -- all (let's call them s0 and s1) start with sample 0, but
at the point in time as s0's sample 0 "propagates" to the block where
the two sample flows are mixed together, due to delay there is no
sample from s1; so the scheduler has to wait until there is enough
input on both input ports of the mixing block. Depending on buffer
size and production rate, this might lead to overruns on s0, or
underruns on a potential hardware sink behind that block.

> Moreover, I'm sure throttle block and audio hardware clock are
> synchronous, because throttle block timing and audio driver
> scheduling both derive from same hardware generator, doesn't they
> ?
Moreover, I'm sure you still didn't understand what throttle does:
exactly nothing useful.
It's an artificial software hack to slow down the average sample
processing rate by blocking in work(). YOU NEVER EVER EVER DO IT in a
flowgraph with hardware. It can only lead to overflows, underflows.

>> 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).
> 
> That's why I already asked what other methods exists besides
> blocking. If it doesn't stimulate OS to switch context (by means of
> blocking calls), then it consume all available CPU time (it doesn't
> matter what kind of activity: signal processing, checking status,
> polling hardware flags, or whatever). So, it still seems to be that
> audio sink uses blocking.
The audio sink has to communicate with audio hardware. However your
system does that, the audio driver interface can only consume a
defined amount of samples per second and only has a limited buffer size.
Therefore, the call that writes samples into the device usually is a
blocking one. You see-- this is hardware with a fixed sampling rate,
so blocking is an effect, not a method.


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

iQEcBAEBAgAGBQJSnwmGAAoJEAFxB7BbsDrLrRUH/0uFi17FJjvQWx22wwpiHgQz
g+UHppH12GOZddfCnGvHXbm3JBOILYDJ2cScdgLFFNshWZFV1r2z2ko6knvi5FBl
MHtjRBTFheyMuONNEetPDNRQZL6KuKrB7EAUuflmJ+D/roZjR6N9aC81mI0qsOVL
mSZzmJbXM35mY0OvRDGx82MxpNzM94z7aLRqhiwXKRvMy8VwEwPBLrLgTYXy1MJe
A7K++4S8LNROoFAFHY+QQ85EJ2oVb3b1O/r/j4f80YTJ+l9LYDwVqu2yy72XVgpH
9lHvgcTFR59ISUcQRPZDUkVtffPhF6ON+Nz/Dm4jWj22ZbttaHH8U24wTtPJZvk=
=FBY0
-----END PGP SIGNATURE-----