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

[Marcus Müller]

-----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 address@hidden 
> 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-----