> 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. > Then: The problem now *obviously* has been reduced to the audio > interface in the VM. > If that's what your application needs, then consider contacting the > developers of the virtualization solution, or just stick with the > obvious: Virtualization strives to make the running of a guest OS but > a process in the Host OS. So, if asynchronizity up to the point of > distorted audio occur, it's not a GR problem, insist on that as much > as you want, but a problem of doing things that need real time > operating system interaction (though with relatively large tolerance > and intervals) such as audio output in a VM which has seemingly not > 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. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
