# Locking TopBlock stops WavFile-Sink

**URL:** <https://www.ruby-forum.com/t/locking-topblock-stops-wavfile-sink/233703>\
**Category:** GNU Radio\
**Created:** [January 5, 2015, 1:22pm UTC](https://www.ruby-forum.com/t/locking-topblock-stops-wavfile-sink/233703 "2015-01-05T13:22:40Z")\
**Posts on this page:** 9\
**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, 1:22pm UTC](https://www.ruby-forum.com/t/locking-topblock-stops-wavfile-sink/233703/1 "2015-01-05T13:22:40Z")

</div>

It looks like there is an issue where locking/unlocking the TopBlock  
causes WavFile-Sink to stop recording. A plain File-Sink does not have  
this problem. This problem is new to 3.7 and didn’t exist in 3.6. Is  
this the intended behavior? I am doing something wrong? Should I be  
using Stop/Wait?

I have put together an even more simplified C++ program here:

> **[GitHub - robotastic/topblock-lock: locking the topblock cause wavfile sinks...](https://github.com/robotastic/topblock-lock)**
>
> locking the topblock cause wavfile sinks to stop recording - GitHub - robotastic/topblock-lock: locking the topblock cause wavfile sinks to stop recording

[https://github.com/robotastic/topblock-lock](https://github.com/robotastic/topblock-lock)  
When you run it, the wav file will stop growing after 5 secs when the  
graph is locked/unlocked and the file sink raw file will keep growing.

To compile, do ‘cmake .’ then ‘make’ then ‘topblock-lock’

Here is the basic code:

time\_t last\_monkey;

gr::top\_block\_sptr tb;  
gr::blocks::vector\_source\_f::sptr src;  
gr::blocks::throttle::sptr throttle;  
gr::blocks::wavfile\_sink::sptr wav\_sink;  
gr::blocks::file\_sink::sptr raw\_sink;  
char filename[160];  
char raw\_filename[160];

volatile sig\_atomic\_t exit\_flag = 0;

void exit\_interupt(int sig){ // can be called asynchronously  
exit\_flag = 1; // set flag  
}

int main(int argc, char \*\*argv)  
{

std::string device\_addr;  
double samp\_rate=32000;

signal(SIGINT, exit\_interupt);

```
tb = gr::make_top_block("Main");

vector<float> floatVector;

```

srand((unsigned)time(NULL));

for (int i =0; i \< 2000; i++){  
float r = static\_cast (rand()) / static\_cast   
(RAND\_MAX);  
floatVector.push\_back(r);  
}  
src = gr::blocks::vector\_source\_f::make(floatVector,true);  
throttle = gr::blocks::throttle::make(sizeof(float), samp\_rate);

std::stringstream path\_stream;  
path\_stream \<\< boost::filesystem::current\_path().string() \<\<  
“/recordings”;

boost::filesystem::create\_directories(path\_stream.str());  
sprintf(filename, “%s/main-0.wav”, path\_stream.str().c\_str());  
wav\_sink = gr::blocks::wavfile\_sink::make(filename,1,samp\_rate,16);  
sprintf(raw\_filename, “%s/main-0.raw”, path\_stream.str().c\_str());  
raw\_sink = gr::blocks::file\_sink::make(sizeof(float), raw\_filename);

tb-\>connect(src,0,throttle,0);  
tb-\>connect(throttle,0,wav\_sink,0);  
tb-\>connect(throttle,0,raw\_sink,0);

last\_monkey = time(NULL);

tb-\>start();

while (1) {  
if(exit\_flag){  
printf(“\n Signal caught!\n”);  
tb-\>stop();  
return 0;  
}  
if ((time(NULL) - last\_monkey) \> 10) {  
last\_monkey = time(NULL);  
tb-\>lock();  
tb-\>unlock();  
}  
}  
// Exit normally.  
return 0;  
}

---

<div class="post-metadata">

**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\
**Post date:** [January 5, 2015, 1:35pm UTC](https://www.ruby-forum.com/t/locking-topblock-stops-wavfile-sink/233703/2 "2015-01-05T13:35:05Z")

</div>

Hi,

When there is a lock()/unlock() cycle, the -\>stop() will end up being  
called on all the flowgraph() blocks.

The wavsink block does implement stop() and that’s where it closes the  
file and updates the wavheader.

But there is no implementation for start(), it actually opens the file  
in the constructor, so it can’t resume.

Cheers,

```
Sylvain
```

---

<div class="post-metadata">

**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\
**Post date:** [January 5, 2015, 3:47pm UTC](https://www.ruby-forum.com/t/locking-topblock-stops-wavfile-sink/233703/3 "2015-01-05T15:47:19Z")

</div>

Awesome! That is totally it.

I went back and checked and the 3.6 version of wavfile\_sink\_impl does  
not  
have a stop function. It only closes the file when close() is called or  
the  
destructor.

This is a pretty big change from 3.6 to 3.7 and I didn’t see it  
documented  
anywhere. Is this something I can add to the 3.6 -\> 3.7 guide in the  
wiki?  
Is there a better place to capture some of the lower level changes?

Are there any good guides that walk through the flows for high level  
functions? Like what calling lock() triggers in the blocks and the  
scheduler? It would make it a lot easier to walk through the code.

In order to solve my problem, it looks like I should create a custom  
version of wavfile\_sink that doesn’t have stop().

Thanks again!

- Luke

---

<div class="post-metadata">

**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\
**Post date:** [January 5, 2015, 4:25pm UTC](https://www.ruby-forum.com/t/locking-topblock-stops-wavfile-sink/233703/4 "2015-01-05T16:25:11Z")

</div>

On Mon, Jan 5, 2015 at 9:45 AM, Luke B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Awesome! That is totally it.
> 
> I went back and checked and the 3.6 version of wavfile\_sink\_impl does not  
> have a stop function. It only closes the file when close() is called or the  
> destructor.
> 
> This is a pretty big change from 3.6 to 3.7 and I didn’t see it documented  
> anywhere. Is this something I can add to the 3.6 → 3.7 guide in the wiki?  
> Is there a better place to capture some of the lower level changes?

That’s the best place to add this change.

> 

You could try and modify the code to overload the start() function to  
open/reopen the file again (can’t say for sure this will be safe with a  
wav  
file, though). Though probably easiest to create your own block as part  
of  
any oot module you’ve built for your projects.

Tom

---

<div class="post-metadata">

**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\
**Post date:** [January 5, 2015, 5:00pm UTC](https://www.ruby-forum.com/t/locking-topblock-stops-wavfile-sink/233703/5 "2015-01-05T17:00:34Z")

</div>

On Mon, Jan 5, 2015 at 10:44 AM, Sylvain M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> apparently multiple start()/stop() calls by the scheduler is something
> 
> Sylvain

This sounds like a good idea.

Tom

---

<div class="post-metadata">

**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\
**Post date:** [January 5, 2015, 5:09pm UTC](https://www.ruby-forum.com/t/locking-topblock-stops-wavfile-sink/233703/6 "2015-01-05T17:09:53Z")

</div>

I will give it a try and see if I can make a start() that does this.

One last question - does calling lock() in a HeirBlock2 just lock and  
call  
stop() on the internal blocks of the HeirBlock2 graph? or does it bubble  
up  
all the way to the TopBlock and cause a lock there?

I am trying to figure out why calling lock() on one instance of a  
HeirBlock  
cause all the other instances to lock().

---

<div class="post-metadata">

**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\
**Post date:** [January 5, 2015, 4:45pm UTC](https://www.ruby-forum.com/t/locking-topblock-stops-wavfile-sink/233703/7 "2015-01-05T16:45:41Z")

</div>

Hi,

> You could try and modify the code to overload the start() function to  
> open/reopen the file again (can’t say for sure this will be safe with a wav  
> file, though). Though probably easiest to create your own block as part of  
> any oot module you’ve built for your projects.

I’d tend to say that the included block should support that. Since  
apparently multiple start()/stop() calls by the scheduler is something  
blocks should handle gracefully.

I’d assume stop() was made to close the file to ensure the header is  
properly written.  
But it could just update the header and seek back to the end without  
actually closing the file and let the destructor do the close on the  
fd.

Cheers,

Sylvain

---

<div class="post-metadata">

**Author:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\
**Post date:** [January 5, 2015, 5:53pm UTC](https://www.ruby-forum.com/t/locking-topblock-stops-wavfile-sink/233703/8 "2015-01-05T17:53:18Z")

</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:** ![hagus](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/9de053/32.png) [@hagus](https://www.ruby-forum.com/u/hagus)\
**Post date:** [January 8, 2015, 3:51am UTC](https://www.ruby-forum.com/t/locking-topblock-stops-wavfile-sink/233703/9 "2015-01-08T03:51:29Z")

</div>

> Yes, a lock/unlock event affects the whole flowgraph, by necessity.
> 
> Reconfiguring flowgraphs should be considered a very big hammer, often  
> used in cases that can be solved some less invasive way.

Just in case anyone is looking for a less invasive way to dynamically  
configure a graph

I just tried out Copy block and it seems to be a great way to turn on  
and off segments of a flow graph. I was locking & unlocking a graph to  
remove and add blocks.

This seems more elegant and prevents any problems with the WavFile-Sink.

> **[GNU Radio Manual and C++ API Reference: gr::blocks::copy Class Reference](https://www.gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1copy.html)**

[http://gnuradio.org/doc/doxygen/classgr\_1\_1blocks\_1\_1copy.html](http://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1copy.html)