Hi Marcus
Hopefully your seeing this, for some reason that other
thread<http://lists.gnu.org/archive/html/discuss-gnuradio/2014-02/msg00351.html>is
no long in my mail inbox or trash..
My problem was:
VLC - Named Pipe 1 - File Source GRC - OFDM MOD - USRP Sink- USRP -Source -
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
using:
cvlc v4l2:///dev/video0 :v4l2-width=160 :v4l2-height=120
:v4l2-aspect-ratio=4/3 --noaudio
--sout="#transcode{vcodec=h264,vb=1024}:file{dst=./txPIPE.ts}" :sout-keep
and reading with mplayer, where the error only occurs when I introduce the
USRP N210 to the circuit.
You had asked what was crashing, the play or the grc produced python set up.
It is the python/GNU radio that is crashing.
I have also had it report the following:
*** glibc detected *** python: realloc(): invalid pointer: 0x0a9c9450 ***
or
*** glibc detected *** python: malloc(): smallbin double linked list
corrupted: 0x0a9efcb8 ***
I have trouble seeing how this should be failing like this as I have used
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 had
expected that would all be taken care of by back pressure if nothing is
really specified.
I really am following the set up Alexandru Csete'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
straight forward.
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 along
the way getting to that point were very different. But now that I have that
part sorted, the players don't complain or crash with what I am trying to
do.
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 been
ignoring it:
UHD Warning:
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 warning.
But if I do have USRP buffer size problem, that does relate to segfaults,
malloc etc...
This is rather beyond my USRP knowledge level though....
cheers
Alexander Buckley
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
