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. As 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



_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to