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
