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

[Artem Pisarenko]

> As I told you before: That's plainly not true. 
> There are a lot of flowgraphs that have both hardware sources and sinks. 
> Why your's not working is a mystery to me, because, seriously, audio 
> sample rates should pose no problem for a moderately capable PC, 
> unless you do something complicated.

Hmm... It means, my issue didn't solved actually. I'm not doing anything
complicated. Could you point me what should I check to find out what's the
problem ? Is it because I run graph on virtual machine ? The only thing I
can tell you surely, it's not because of slow performance. (I made graph:
"audio source -> my sink block (transmit to localhost)", "my source block
(receive from localhost) -> audio sink", and it works like a sharm: sound is
clean, cpu load near few percents.)


> The scheduler is a *scheduler*, it schedules the calling of the work 
> functions. I don't think you realize the implications of designing a 
> per-sample real-time signal processing framework.

Maybe. Per-sample ?


> It basically 
> eradicates the possibility of having variable computational costs in 
> each block. 
> And, by the way, I think you over-estimate the real-time abilities of 
> modern operating systems on modern PC hardware. If you want to have a 
> guaranteed "sample clock" in GNU Radio, you would need HUGE amounts of 
> spare computational power. That'd be a waste. 
> GNU Radio works on *blocks* of samples. This implies latency, and 
> makes it impractical to say "ok, that single sample always comes every 
> x µs", but it gives you the advantage of a buffer, so that you can 
> have actual hardware interaction with your SDR. 

Why it ought to be per-sample based ? There are no requirement for every
single sample to come at fixed interval, only average total rate is fixed. I
don't see any conflict between "real-time" and operating on blocks of
samples at a time (even with variable size). Scheduler perfectly manages
buffers, so I don't see any problems to prepare input buffer (source buffer)
large enough to mitigate variable computational costs and other system-wide
events. Yes, it's unavoidable latency, until we have real-time OS. And what
did you mean under guaranteed sample clock ? It actually is, otherwise
things wouldn't worked clean. If there are no sufficient computational
performance to run given task in real-time, then it will not be possible
even in current design.
I just talked about idea to move out all time-synchronization at some single
global place.

I think it's a long discussion, but it meaningless, since you stated that
things should work as expected even in current design. So, I have to
investigate what's going wrong in my case...



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