Hi everyone,
FYI, here is the general announcement of and motivation for the changes:
> https://lists.gnu.org/archive/html/savannah-hackers-public/2019-06/msg00018.html
> https://lists.gnu.org/archive/html/savannah-hackers-public/2019-09/msg00016.html
Adrian Musceac:
> I have to agree with
hamzeh elsayed:
> I wrote a c code program to write in fifo in file to use it instead of cat
> in.
>
> The result was the same.
I'd still believe the error is in the way you interact with the fifo.
Have you looked at setvbuf() or fflush()?
(e.g. "setvbuf(f, (char *)NULL, _IONBF, 0);" )
ali mokdad:
> do you know a special program I can test?
"stdbuf" could be of help here. But beware that the input stream into
"cat" may still be (line) buffered because of bash.
Example:
$ stdbuf -i 0 -o 0 cat > in
Cheers!
___
Discuss-gnuradio
Hi,
Ramazan Çetin:
> I have digged some more. This is how the connection is . OFDM MOD ->
> RATIONAL_RESAMPLER -> MY_BLOCK
>
> Everytime, 64 items remains inside of rational_resampler block. When my
> block is called by scheduler, i have logged the below. I am waiting 1950
> sized input for
If you are on Linux you could just create a file in tmpfs (i.e. RAM).
Use a File Sink with a file in "/dev/shm" for instance (see "man mount"
to configure tmpfs).
Of course you then probably need a lot of RAM (or can capture only small
durations). But it is much faster than disk I/O...
Müller,
N. Benes:
> what is the accepted best practice to have a source and a sink block
> share a common resource?
> In my case, the shared resource is a thread that does I/O and both
> source/sink use it to interface to GNU Radio.
[snip]
> Is there a commonly accepted p
Hi GNU hackers,
what is the accepted best practice to have a source and a sink block
share a common resource?
In my case, the shared resource is a thread that does I/O and both
source/sink use it to interface to GNU Radio.
First I thought about adding the I/O thread to the source block and use
