# Issue with Virtual Sink/Source

**URL:** <https://www.ruby-forum.com/t/issue-with-virtual-sink-source/233712>\
**Category:** GNU Radio\
**Created:** [January 5, 2015, 5:58pm UTC](https://www.ruby-forum.com/t/issue-with-virtual-sink-source/233712 "2015-01-05T17:58:16Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\
**Post date:** [January 5, 2015, 5:58pm UTC](https://www.ruby-forum.com/t/issue-with-virtual-sink-source/233712/1 "2015-01-05T17:58:16Z")

</div>

Hi,

We recently bought a new PC with some powerful specs. GNU Radio was  
built  
from the source and it seems to be installed fine. However, when I try  
to  
use the virtual sink and source blocks in my flow graph, I am getting  
the  
following error:

Traceback (most recent call last):  
File “./test\_skh.py”, line 595, in   
tb = test\_skh()  
File “./test\_skh.py”, line 486, in **init**  
self.connect((self.virtual\_source\_0, 0),  
(self.blocks\_multiply\_conjugate\_cc\_0, 0))  
File  
“/usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier\_block2.py”,  
line 93, in **getattr**  
return getattr(self.\_impl, name)  
_AttributeError: ‘top\_block\_sptr’ object has no attribute  
‘virtual\_source\_0’_

Once I replace the virtual blocks with direct connections, things work  
just  
fine. What is the cause for this problem and how to fix it?

Please note that on an older machine, GNU Radio was installed around a  
month ago following the same procedure followed here, and the virtual  
sink/source blocks work just fine.

Thank you.

Best regards,  
Khalid

---

<div class="post-metadata">

**Author:** ![khalide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/3bc359/32.png) [@khalide](https://www.ruby-forum.com/u/khalide)\
**Post date:** [January 5, 2015, 6:12pm UTC](https://www.ruby-forum.com/t/issue-with-virtual-sink-source/233712/2 "2015-01-05T18:12:32Z")

</div>

On 01/05/2015 11:57 AM, khalid.el-darymli wrote:

> File “./test\_skh.py”, line 486, in **init**  
> Once I replace the virtual blocks with direct connections, things work
> 
> * * *
> 
> Discuss-gnuradio mailing list  
> [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
> [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)  
> My guess is that this machine has GR installed from the official repos  
> as well, and you’re getting an old GR instance.

---

<div class="post-metadata">

**Author:** ![khalide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/3bc359/32.png) [@khalide](https://www.ruby-forum.com/u/khalide)\
**Post date:** [January 12, 2015, 11:26pm UTC](https://www.ruby-forum.com/t/issue-with-virtual-sink-source/233712/3 "2015-01-12T23:26:56Z")

</div>

Hi,

I’m having the same issue as Khalid. I just updated my GNU Radio source  
based installation on two different machines. On one of the machines I  
previously had a source installation of gnuradio 3.7.4. This machine  
runs  
Linux Mint 17.1, the other machine runs Ubuntu 14.04. A flow graph  
utilising virtual sources and sinks that ran fine under gnuradio and  
gnuradio-companion 3.7.4 now throws up the same error as Khalid has  
pointed  
out, on both my Linux Mint and Ubuntu machines.

Anyone else seeing this behaviour? Any ideas?

Thanks

Cheers  
Richard

On 6 January 2015 at 05:57, khalid.el-darymli [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![khalide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/3bc359/32.png) [@khalide](https://www.ruby-forum.com/u/khalide)\
**Post date:** [January 13, 2015, 2:45am UTC](https://www.ruby-forum.com/t/issue-with-virtual-sink-source/233712/4 "2015-01-13T02:45:08Z")

</div>

* * *

Discuss-gnuradio mailing list  
removed\_email\_address@domain.invalid  
[https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)

---

<div class="post-metadata">

**Author:** ![khalide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/3bc359/32.png) [@khalide](https://www.ruby-forum.com/u/khalide)\
**Post date:** [January 13, 2015, 2:52am UTC](https://www.ruby-forum.com/t/issue-with-virtual-sink-source/233712/5 "2015-01-13T02:52:54Z")

</div>

* * *

Discuss-gnuradio mailing list  
removed\_email\_address@domain.invalid  
[https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)

---

<div class="post-metadata">

**Author:** ![khalide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/3bc359/32.png) [@khalide](https://www.ruby-forum.com/u/khalide)\
**Post date:** [January 13, 2015, 2:02pm UTC](https://www.ruby-forum.com/t/issue-with-virtual-sink-source/233712/6 "2015-01-13T14:02:03Z")

</div>

Thanks Johnathan for the update.  
BTW, with the recent installation, I am also getting the following  
warning  
when running my GRC or the GRC-generated python script,

fft\_impl\_fftw: /home/ov/.gr\_fftw\_wisdom: Permission denied  
fft\_impl\_fftw: /home/ov/.gr\_fftw\_wisdom: Permission denied  
fft\_impl\_fftw: /home/ov/.gr\_fftw\_wisdom: Permission denied  
.  
.  
.  
fft\_impl\_fftw: /home/oceanview/.gr\_fftw\_wisdom: Permission denied

This warning is repeated in the terminal like 100 times before the  
script  
actually runs. I am not sure why?

Thanks.

Best regards,  
Khalid

On Mon, Jan 12, 2015 at 10:21 PM, Johnathan C.  
\<removed\_email\_address@domain.invalid

---

<div class="post-metadata">

**Author:** ![khalide](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/3bc359/32.png) [@khalide](https://www.ruby-forum.com/u/khalide)\
**Post date:** [January 13, 2015, 2:18pm UTC](https://www.ruby-forum.com/t/issue-with-virtual-sink-source/233712/7 "2015-01-13T14:18:19Z")

</div>

Hi,

> fft\_impl\_fftw: /home/oceanview/.gr\_fftw\_wisdom: Permission denied
> 
> This warning is repeated in the terminal like 100 times before the script  
> actually runs. I am not sure why?

Erase that file.

My guess is that it was created when something was run as root and now  
you can’t write to it as a normal user.

Cheers,

Sylvain
