Hopefully your seeing this, for some reason that other
no long in my mail inbox or trash…
My problem was:
VLC - Named Pipe 1 - File Source GRC - OFDM MOD - USRP Sink- USRP
OFDM DEMOD - File Sink GRC - Named Pipe 2 - Mplayer
(FAILS!!). Reports: Segfault (core dumped). GRC file is running, VLC is
streaming. Fail occurs as soon as I open Named Pipe 2 with Mplayer
cvlc v4l2:///dev/video0 :v4l2-width=160 :v4l2-height=120
and reading with mplayer, where the error only occurs when I introduce
USRP N210 to the circuit.
You had asked what was crashing, the play or the grc produced python set
It is the python/GNU radio that is crashing.
I have also had it report the following:
*** glibc detected *** python: realloc(): invalid pointer: 0x0a9c9450
*** glibc detected *** python: malloc(): smallbin double linked list
corrupted: 0x0a9efcb8 ***
I have trouble seeing how this should be failing like this as I have
the same set up to send a text file, with the only difference being that
the file read is set to repeat.
I have been thinking there could be trouble with data rates, though I
expected that would all be taken care of by back pressure if nothing is
I really am following the set up Alexandru C.'s. The only differences
being is that he is using a mac book, older usrp1 and gstreamer.
But i don’t any of that should be the difference, the commands are quite
I had to try quite a few combinations of streamers/players to get it
to work initially without GRC stuff in the loop. The errors presented
the way getting to that point were very different. But now that I have
part sorted, the players don’t complain or crash with what I am trying
It is the GRC-python file when the USRP is added. I am using my USRP for
all sorts of other things just fine though.
So again I keep coming back to data rates, buffers etc.
I do have this always displayed when i run my USRP, I have just always
The send buffer could not be resized sufficiently.
Target sock buff size: 1048576 bytes.
Actual sock buff size: 131071 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=1048576
Running sudo sysctl -w net.core.wmem_max=1048576 doesn’t stop this
But if I do have USRP buffer size problem, that does relate to
This is rather beyond my USRP knowledge level though…