Hi Marcus, No... that didn't do it. In fact, connected UDP source to null sink and still get console full of warnings. I think something is wrong somewhere, maybe in network setup or network stack of BBB. If anyone has achieved something similar, (sample forwarding), do feel free to post your grc files. :)
I would try TCP.. but it seems to be coupled with grc, but Beaglebone is headless! Ack... On Sat, Aug 10, 2013 at 3:41 AM, Marcus Müller <mar...@hostalia.de> wrote: > Hi Vanush, > remove the gui sink. It also limits the sample processing speed and thus > is equally bad as throttle. > > Am 09.08.2013 19:33, schrieb Vanush Vaswani: > > 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> 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. >> 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>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
