You already proposed a workaround - use a network sink. It jumps
through a fraction of the loops to get your audio out of the VM into
your host.
I used purely VM-internal network (loopback interface). Experiments with
network and ‘Delay’ block clearly demonstrate simple lack of buffering
in
direct connection between audio source and sink.
been configured correctly to do this.
I think we just misunderstand each other. Maybe because my english is
not
good enough to express thoughts correct. I would believe you if my
second
experiment didn’t show me results, which disprove your conclusion. My
experiment doesn’t show actual reason, but it excludes the reason you
insist
on. I will believing it until someone will disprove my conclusions made
from
that second experiment (for example, “your custom network blocks contain
some tricky bug which fortunately restores synchronization broken at
VM-host
border, that’s why it works”).
Again, I think you wrongly associate “real-time” term with (almost)zero
latency. Real-time doesn’t define exact latency value, it just
guarantees to
keep it constant. But there are no hard real-time in linux, and it
doesn’t
prevent things from working properly, as I demonstrated already. All
that is
needed is just sufficient buffering. And buffering introduces latency
(in my
case minimal achievable value is (6699 samples)/(48000 samples per sec)
=
0,140 sec, and it suits me).
Marcus, I don’t insist on discussion, but you provoke me to defend my
position again and again. 
Please, don’t get me wrong.
–
View this message in context:
http://gnuradio.4.n7.nabble.com/how-to-implement-synchronous-source-block-correctly-tp45083p45236.html
Sent from the GnuRadio mailing list archive at Nabble.com.