-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ok, Artem, as has been pointed out: Do this in a separate thread with indicative subject.
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. 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. Sincerely, Marcus PS: regarding your throttle confusion: You can trust Martin. And: Read the full paragraph. It is clear. You miscite the sentence out of context. On 06.12.2013 05:31, Artem Pisarenko wrote: > Martin Braun (CEL) wrote >> If you *directly* connect audio source to sink, you can run into >> the problems you describe -- depending on the backend (my >> intuition says, Jack would handle that better than ALSA, haven't >> tried). > > Yes, I made several experiments, and problem exists only when they > connected directly. I've tried Jack but run into another adventures > and finally wasn't able to get it work at all. > > >> 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... > > Yes, exactly. But also it doesn't seem to be problem in > virtualization, because after I complicate this chain by adding > simple buffered network transfer (thus making connection > *indirect*), it works perfect ! > > I think Martin pointed to right direction - problems are somewhere > between gnu radio and audio backend. I've played with audio block > properties and didn't found any consistent pattern... Some > observations: - when I specify device name 'hw:0,0' (instead > leaving it empty), it works well (there are no 'aU' messages at > all) - when I change 'ok to block' value it works less or more > better Anyway, since this problem exists only with direct > connection, it's not critical. Even inserting just single 'Delay' > block with delay value >=6699 (at sample rate 48000) completely > solves issue for me. I just worried that even if such simple test > connection not work, then my application will not work too, but > everyting ok (still). > > Thanks again for responses ! > > P.S. Martin said that only sources are allowed to block, but > 'Throttle' docs says: "...That should be controlled by a *source or > sink* tied to sample clock." I'm implementing sink block as well, > and these contradictory statements confuse me a bit... > > > > -- View this message in context: > http://gnuradio.4.n7.nabble.com/how-to-implement-synchronous-source-block-correctly-tp45083p45228.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/ iQEcBAEBAgAGBQJSoX1ZAAoJEAFxB7BbsDrLB/wH/3/P/k+UYPth6VDccjs8yFdJ tBX4KPsKU0T5Jfa6Ll+Upza6BkdFD24L/6lxAnAlkg+lcz4V+ckB+HJ4DmP73SE0 tNDvBiIhRID4GZHJE75MMwDOetRow3a16kTQsbrcxbS+MIkK3X+B/rHdTKEwXfCK j+eq5xD56GT/i9jsL+8dAX9vqht5V4hwji5kfNAMAAKOA8mZMi9Xu6E62l2sZPKi HmVPMXg03iB46MbjO2RNZXqF8wlZFe/wnhiY1lvp0yo+RfC9YIXLVYoB7P9beP9b GZJh2iTmrdvcT2uGMS0iw3ZmAKKz2Mkrv9Pkj9QHRJiP0XAj/SGjXoxUTA+edk8= =2PGf -----END PGP SIGNATURE----- _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
