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

[Artem Pisarenko]

>> No, it's just ambiguous terminology. How should we call blocks producing 
>> output synchronously with some reference source ? 
> We call them 'source block'.

OK.


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

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.


> You still have two clocks in one flow graph. Underruns can still happen.

Why ??? These clocks are actualy same clock. They are synchronous. 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 ?


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



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/how-to-implement-synchronous-source-block-correctly-tp45083p45147.html
Sent from the GnuRadio mailing list archive at Nabble.com.