-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks for the long reply! Um, yeah, I think I might have argued in another issue than you. Ok, so the point is, what I thought you were proposing was a common clock that was basically determining at which rate samples go in and out of blocks; and I was arguing that that kills efficiency and flexibility, because the scheduler (as it is) tries to process as many samples as possible. "As possible" is limited only by the speed at which samples can be produced and consumed by sources or sinks, and the time the work functions need to computate. Having a fixed clock would obviously let some blocks sleep if they have processed "enough" samples for the clock cycle; that would lessen the overall performance that GNU Radio achieves, by taking all the samples it can get out of the sources.
However, I think the problem is exactly what I was trying to describe: let all blocks start on a common timebase. This leads to clock-synchronous pipelining of sample processing, leading to periodic "dead" times for most of the "fast" blocks while they wait for input from the slow blocks. In the case of congestion this clock-synchronous behaviour leads to unnecessary problems. Yet I don't understand the advantage of being clock-synchronous... To your actual problem: Did I get that right: Real world > soundcard > Host OS > Virtualization > VM Guest OS > GNU Radio audio source > GNU Radio audio sink > VM Guest OS > Virtualization > Host OS > soundcard ? In this case, I don't think the problem is in your GNU Radio app... Greetings, Marcus On 05.12.2013 12:43, Artem Pisarenko wrote: > >> 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSoGz3AAoJEAFxB7BbsDrLXIUH/jSfimYtG2Qvlf8jPOYdxW5n zC41x/c76Nqi/y+UaQootwD/Jfa7OzfGzOItZQp12tNzUKUy8zNkFh9i+/XernNr qjfDStHy1bjCNziZmOXORokJ+fKiLeOI8EqbrNwFPycizjWaDaFvTdBAlE2oXqQ4 MfFPS0Y44fl8CPh6dnojIkMiduKeCSKig0MU+DWA2ZO5+aDAwoFPTxKpa17RwVxC hzGhjFnPkQn278sXzPTLGPFD3fG94KCuEdEjySons4+PMQWtZeDKBIhLoRnNIAQX 0gKb7zzehQd5UX3yNZz4ccbz5gBzfDjTqC7dUPXNocDGCaL9olS8Vinvosx92as= =k/by -----END PGP SIGNATURE----- _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
