Re: [Discuss-gnuradio] Resampling audio using rational resampler doesn't work for multimon-ng

[Ignatius Rivaldi]

Nah, I gonna stick to named pipe, as all processing is local to this
computer, as I used sox and UDP because I followed a guide somewhere
and I want to move the resampler inside Gnuradio to clean up the code

On Fri, May 24, 2019 at 5:38 PM Marcus Müller <address@hidden> wrote:
>
> Hum, this is a wild guess, but the sox aspect reinforced it:
>
> somewhere, there's a network buffer overflowing. If that interpretation
> is right, sox just adds a quickly-absorbing buffering layer to the
> processing chain.
>
> In any case, would sound like the pipe approach would be best. Is there
> a reason not to use it? Maybe we can come up with a way to make
> whatever it is work :)
>
> Best regards,
> Marcus
>
> On Fri, 2019-05-24 at 13:29 +1000, Ignatius Rivaldi wrote:
> > sox is the magic thing that makes netcat and multimon-ng works. Even
> > if I don't do any resampling, ie sox -t raw -esigned-integer -b 16 -r
> > 22050 - -esigned-integer -b 16 -r 22050 -t raw - and use the UDP
> > channel from the resampled audio it works, while if I  in I pipe
> > netcat directly into multimon-ng it doesn't work
> >
> > On Fri, May 24, 2019 at 1:24 PM Ignatius Rivaldi
> > <address@hidden> wrote:
> > > Its the UDP sink. If I use File Sink to a named pipe file multimon-
> > > ng
> > > can decode it by using cat pipe | multimon-ng -Aq - but if I use
> > > the
> > > UDP port and netcat -ulk localhost 8000 | multimon-ng -Aq - it
> > > doesn't
> > > decode, so the resampler does work but somewhere in the UDP channel
> > > something corrupts the data
> > >
> > > On Sun, May 19, 2019 at 1:50 AM Kevin Reid <address@hidden>
> > > wrote:
> > > > On Sat, May 18, 2019 at 12:07 AM Albin Stigö <
> > > > address@hidden> wrote:
> > > > > You need to use a low pass filter (taps) in you resampler. Look
> > > > > at the spectrum after the resampler and this will be obvious to
> > > > > you. A lowpass filter with a cutt off at 3-4kHz or so should do
> > > > > it.
> > > >
> > > > This cannot be the problem, because rational_resampler
> > > > automatically calculates a filter if taps are not specified:
> > > > https://github.com/gnuradio/gnuradio/blob/4e4f44c726556496c420bceb87ccafe6843916f7/gr-filter/python/filter/rational_resampler.py#L107
> > > >
> > > > (I also checked the GRC file, and the fractional bandwidth is
> > > > also None (auto-set) despite appearing as "0" in the screenshot.)
> > > >
> > > > Unfortunately, I don't have any ideas what the problem is. For
> > > > what it's worth, I have successfully integrated multimon-ng into
> > > > a flow graph (
> > > > https://github.com/kpreid/shinysdr/blob/master/shinysdr/plugins/multimon.py
> > > > ) but the code is very differently structured so it would be hard
> > > > to transfer the knowledge into GRC.
> > > >
> > > > As a next troubleshooting step I would recommend adding GUI sinks
> > > > at various parts of the flow graph so that you can check the
> > > > signal integrity. (For an example, consider adding after the
> > > > float-to-short a short-to-float and QT GUI Sink — to ensure the
> > > > signal hasn't gotten lost in quantization noise and just needs to
> > > > be amplified before converting to short, as well as checking that
> > > > the bandwidth/resampling is good.)
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>