> 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. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
