I measured the throughput with the "Probe Rate" block and figured out that
it's much higher while the underruns are occuring ( > 80k samples) than when
I have no underruns ( ~48k samples).
--
View this message in context:
Well, it outputs the packets from the TUN device, as soon as they arrive
there. Or is it something else you mean?
I am using firdes.band_bass ( Frequency Xlating FIR Filter ) with
- gain: 0.5
- sampling frequency: 20k
- low cutoff frequency: 19k
- high cutoff frequency: 20k
-
At which rate is that tun_source running? and still: what's the specs on
your band-pass filter?
On 20.06.2016 20:32, Paul S wrote:
> Hi Kevin & Marcus,
>
> thank you for your answers. After a while of testing I've got interesting
> results. Firstly, even though it brought 100% CPU load on one
Hi Kevin & Marcus,
thank you for your answers. After a while of testing I've got interesting
results. Firstly, even though it brought 100% CPU load on one core, the
packet encoder is not a problem as the underruns also occured without it.
Anyway, thank you for your suggestion, I'll certainly look
Hi Paul,
I'd like to second Kevin's notion that if anything is limiting your
sample flow, it's the filter in the resampler. I don't know exactly what
type of filter you chose, but I did the following (in python):
from gnuradio import filter as gr_filter
res =
On Jun 18, 2016, at 19:07, Paul S wrote:
> Currently, I am trying to send data over ultrasound signals based on [1],
> using the audio sink and several sources. The problem is that I get often
> consecutive audio underruns (for several seconds straight).
> This is my flowgraph:
Hello everyone,
I am quite new to this and to gnuradio so excuse me if I have some knowledge
gaps.
Currently, I am trying to send data over ultrasound signals based on [1],
using the audio sink and several sources. The problem is that I get often
consecutive audio underruns (for several seconds