Hi,
It doesn't help, I still consistently drop samples.
I tried increasing the buffer size in udp_source_impl.cc. I can
record to .wav perfectly for about two minutes before the flow
graph suddenly exits with (I'm assuming) a segfault.
For reference, I have attached images of the sender and receiver.
Surely, this sort of streaming has been done before? I am using a
BeagleBone Black running Ubuntu 12.04 (which runs fine - no
overflows). The correctness of the FM receiver is less of a
concern than the dropped samples.
Regards,
Vanush
On Sat, Aug 10, 2013 at 3:11 AM, Marcus Müller
<mar...@hostalia.de <mailto:mar...@hostalia.de>> wrote:
Hi Vanush,
ok. Throttle does not _do anything_ with the samples. It just
slows down the computational speed that they are processed
with. Remove it, it breaks your flowgraph.
GRCAs said before, the WARN:... warnings stem from your UDP
source. Data does not get processed fast enough; that's
throttle's fault (before, the audio sink was limiting
your sample processing speed, which is in its nature).
Your flowgraphs are _not_ running at the same rate; they
_may_ process samples at the same average rate (that's what
throttle does, stop the sample flow when it's faster
than specified), but throttle does not convert sample rates.
Refer to existing Receiver flowgraphs from the internet on
how to do things right, and please remember: 192kHz input
MUST be downsampled for audio usage.
Have a nice day,
Marcus Müller
Ok, I still don't understand why I'm getting so many dropped
packets.
sender
FCDPP -> UDP Sink
receiver
UDP Src -> _Throttle_ (at 192KHz) -> WBFM Receive -> Wav
File Sink
Note: no audio sinks.
I constantly get "WARN: Too much data; dropping packet."
Wave file is full of skips, yet both flowgraphs are running
at the same rate?
On Fri, Aug 9, 2013 at 10:37 AM, Iain Young, G7III
<g7...@g7iii.net <mailto:g7...@g7iii.net>> wrote:
On 09/08/13 00:22, Vanush Vaswani wrote:
Hi,
If i add a rational resampler to match the audio
rate before the UDP
sink, I can get a continuous output, but it's of
terrible quality due to
the loss of information.
You are always going to have to throw information away.
You have 192k
that you are trying to fit into human hearing, so you
*must* filter
and then down sample.
How wide is your BPF/LPF ? Is it more than your
soundcard can handle ?
How does the flowgraph work having a sample rate
'mismatch' when the
FCDPP block is in the same graph?!
Your soundcard (probably) expects 44k1. The resampler
takes care of
this, but of course, 192k is not going to go into 44k1.
You need to
filter first.
Could you give me a hint in working around this issue?
As I said before, google has plenty of examples of FM
receivers with grc
(Google for gnuradio FM receiver grc, I'm sure you'll
find loads)
Here are two working flowgraphs that start at 192k and 250k
respectively:
http://hal.g7iii.net/GRC/Examples/Simple_Multimode_RX.png
http://hal.g7iii.net/GRC/Examples/GUI_TRX_JACK.
<http://hal.g7iii.net/GRC/Examples/GUI_TRX_JACK.png>
They are actually a multimode receiver I wrote as an
example for a
friend, and a multimode transceiver for ham radio use,
but they show
the FM receive chain.
With both, you'll note I have a variable BPF so I can
listen to
broadcast stations on MW/LW, and FM, SSB, or CW stations
on the amateur
radio bands.
For pure FM you can drop the selector blocks, and just
concentrate on
the NBFM receiver chain
Note if you need to be tuning with the FIR filter,
you'll need to define
filter taps. I used a simple LPF.
Hope that helps
Iain
