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

[Marcus Müller]

-----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 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/

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-----