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