Hi,
this is very interesting!
As this actually seems to be more of a storage issue, I think
kernel-based solutions might be good, too: (as root)
|echo 90 > /proc/sys/vm/dirty_ratio
echo 75 > /proc/sys/vm/dirty_background_ratio
|
|Should allow your kernel to use up up to 90% of your RAM for writ
As a heads up, I was able to get everything working using only GNURadio
Companion. I tied the USRP Source into a Stream-to-Vector block and
created a 20 MS buffer. From there I sent the 20 MS vector to the File
Meta Sink.
This adds some latency, but for my application this is perfectly OK. I
ha
On 09/07/2014 07:08 PM, Peter Witkowski wrote:
Not sure I follow. If I have a large enough buffer, the data coming
in and the data coming out should be free of concurrency issues and
should be able to work just fine. That is, as long as the producer
thread can keep adding data to the message q
Not sure I follow. If I have a large enough buffer, the data coming in and
the data coming out should be free of concurrency issues and should be able
to work just fine. That is, as long as the producer thread can keep adding
data to the message queue, I should be OK. If it gets locked out due to
Try messing around with the buffer size in
gnuradio-runtime/lib/flat_flowgraph.cc
#define GR_FIXED_BUFFER_SIZE
On Mon, Sep 8, 2014 at 6:24 AM, Peter Witkowski wrote:
> Hello,
>
> I have a simple application written in Python using GNURadio. All I am
> trying to accomplish is to have the USRP da
On 09/07/2014 04:24 PM, Peter Witkowski wrote:
Hello,
I have a simple application written in Python using GNURadio. All I
am trying to accomplish is to have the USRP data be written to disk.
The application works fine when I dump data to /dev/null or run it at
reduced sampling rates. Howev
