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

[Marcus Müller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You exactly reproduced what I was trying to say -- the problem is most
probably that GNU Radio uses the audio device as if it was an actual
audio device. But it's not. The virtualization breaks the "easy to
achieve" real-time needed for audio playback.
Therefore more buffering is necessary. As Martin described, having an
additional layer of buffers can solve audio problems. You did that
with network loopback.
But these problems are only there because VM audio doesn't work like
"real" audio. Still not a GR bug :) Long story short: Don't use your
VM to play audio, if it does not work reliably.

Greetings,
Marcus

On 06.12.2013 12:25, Artem Pisarenko wrote:
> 
>> 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 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/

iQEcBAEBAgAGBQJSobaWAAoJEAFxB7BbsDrLAZ8H/0AHJEhRIyBnh2aSXD1IiZvJ
tKQfBYuN+2j0tbSiuvUT/mbOzx+A+CjF0047UIK9+G6mfp3cu1BnKjyU1s84CSm/
IEFEo2Uwn18aMiqClSAskEY8VosQCCbG1B8mAeIB87nvihKEivhl5fktk1CSwUZq
Fde22I/rjzXh+7lDAabvjmbw7P2ASeyC51S9QwRVKqcgXFy2vnpavK5f8UeWuj0a
qMSYmOi9zMH7LTe5mZtvG2kyh3BRS8kvu+tciUDSM/820Jca5NPxDZcIXqqGJCPQ
JLwa7sirG39jOvpdJ2ZfrCVAWB+pMGGGu8nGA0itcbHtL9XErtRuQRbG8RWqHS4=
=dfl5
-----END PGP SIGNATURE-----