Re: [Discuss-gnuradio] Resampling rate method assistance

[Carlo Manfredini]

My hardware arrangement is fairly demanding, I think ?

I wish to resample between a Red Pitaya connected via ethernet running at 100kSps and a USB-audio unit (UCA-202) running at 48kSps.

This code is simply a "loopback test" for both units running at once.

I would then add some signal processing to the signals in and out once I have these working correctly.

You can also see the break in the audio signal display in the time sink...as well as the aUaUaU...

When I view the PCs system monitor, it is using about 50% resources.

Perhaps the USB-based audio device is struggling to operate continuously given that the RP is communicating via ethernet at about 1000kBps (according to System Monitor).

USB devices tend to be "bursty" and rarely operate continuously without breaks when the PC has other tasks to attend to.

A screenshot of the code is: https://drive.google.com/open?id=1XTNlHB87kNrX82cItMPWMvLGCGXvyr0U

Thanks for any further suggestions.

Maybe an option is to run the USB device at a slower sample rate ?

On 30 May 2018 at 17:51, Müller, Marcus (CEL) <address@hidden> wrote:

I'd assume this might not be a computational issue, but more of a
hardware or hardware interfacing issue, or maybe something
algorithmically off. Care to save a picture of your flow graph (File-
>Screen Capture) and upload it (e.g. imgur.com)?

Thanks,
Marcus

On Wed, 2018-05-30 at 08:25 +1000, Carlo Manfredini wrote:
> Hi Marcus,
> I see. I thought you were referring to the "Polyphase Arbitrary
> Resampler"  block for a polyphase implementation.
>
> Having that optimisation in the "Rational Resampler" is excellent,
> and thank you for the detailed explanation. Very helpful.
>
> I'll look further into why I was getting underflow issues as
> resampling between 100kSps and 48kSps using 12/25 ratios should be no
> problem for my i7 based PC.
> ( I assume that what I was getting: aUaUaU...being printed onscreen
> in GRC..and some breaks in the continuous signal)
>
> Regards.
>
> On 29 May 2018 at 23:19, Müller, Marcus (CEL) <address@hidden>
> wrote:
> > Hi Carlo,
> >
> > if you're using GNU Radio's rational resampler, you're already
> > using
> > that method!
> >
> > Really, at your 100 kS/s rate... things should be trivial for your
> > CPU,
> > even if they weren't implemented efficiently. I'm really not
> > convinced
> > the resampling is to blame here!
> >
> > Best regards,
> > Marcus
> >
> > On Tue, 2018-05-29 at 22:03 +1000, Carlo Manfredini wrote:
> > > Hi Marcus,
> > > Thanks for that reply.
> > > The reduction in computation with the polyphase implementation
> > sounds very tempting esp as I'm getting underflow errors at the
> > moment.
> > > I will give it a try and see how it compares.
> > > Regards.
> > >
> > > On 29 May 2018 at 19:34, Müller, Marcus (CEL) <address@hidden>
> > wrote:
> > > > Hi Carlo, hi Linda:
> > > >
> > > > as Linda said,the RR approach works really well and is
> > numerically
> > > > relatively stable until you hit really ugly ratios (after, of
> > course,
> > > > cancelling the fraction as far as possible).
> > > > But what is "ugly" here?
> > > >
> > > > In theory, rational resampling by M/N (note: M,N coprime!)
> > would work
> > > > like the following
> > > >
> > > > input --> insert (M-1) zeros between each sample
> > > >       --> low-pass 1/M-band filter to get rid of the images
> > > >       --> low-pass 1/N-band filter to avoid aliasing in next
> > step
> > > >       --> throw away (N-1) of N samples --> output
> > > >
> > > > Now, either of the 1/M and the 1/N-band filter doesn't do
> > anything
> > > > useful, simply because the other is narrower.
> > > >
> > > > So, we reduce that to
> > > >
> > > > input --> insert (M-1) zeros between each sample
> > > >       --> low-pass 1/max(M,N)-band filter against images and
> > aliases
> > > >       --> throw away (N-1) of N samples --> output
> > > >
> > > > and pay a bit of attention to the transition width of the
> > filter (which
> > > > will become smaller the closer the ratio M/N becomes to 1).
> > > >
> > > > This is all fine and dandy, but let's say max(M,N) is N=25.
> > > > A quick calculation[1] shows that this filter might have 220
> > taps,
> > > > which we need to apply to 12× the input sample rate, so that's
> > 12·220,
> > > > that is ca 2600, multiply-accumulate operations per input
> > sample –
> > > > ooof.
> > > >
> > > > We avoid that by having an elegant polyphase implementation,
> > which by
> > > > the
> > > > power of greyskull (or was it harris?) allows us to run this
> > core
> > > > filter
> > > > at 1/N of the input rate (instead of M times the input rate!);
> > so, we
> > > > get
> > > > 220 / 25 = 9 multiply-accumulates per input sample - which is
> > very
> > > > bearable, and thus, the rational resampler works very well in
> > this
> > > > scenario.
> > > >
> > > > With M,N coprime, we basically get two good cases:
> > > >
> > > > 1. N >> M (rational decimation): The core filter runs at a very
> > low
> > > > rate of
> > > >    1/N of the input rate, its length being proportional to M·N.
> > > > 2. M >> N (rational interpolation): The core filter runs at a
> > still low
> > > > 1/M
> > > >    of the output rate, its length being proportional to M.
> > > >
> > > > So, the efforts of an M/N and an N/M filter are very
> > manageable,
> > > > because
> > > > either the filter isn't that long (no M factor in the length)
> > or the
> > > > filter
> > > > runs at a very low rate (1/N of the input).
> > > >
> > > > A problem only occurs if M and N are relatively close to each
> > other:
> > > >
> > > > In that case, the transition width of the core filter becomes
> > very
> > > > small, and
> > > > the inverse of transition width goes linearly into the
> > necessary length
> > > > of a
> > > > FIR filter; at the meantime, the polyphase saving don't balance
> > that
> > > > out.
> > > > To make matters worse, a some point, having a polyphase
> > decomposed
> > > > large filter
> > > > becomes a problem for your CPU: while a modern CPU can happily
> > keep a
> > > > couple
> > > > hundred filter coefficients and the same amount of in- and of
> > output
> > > > samples in
> > > > L2 (or even L1) cache, you can quickly get into trouble if the
> > filter
> > > > becomes
> > > > so large that you regularly have to flush your cache; then you
> > quickly
> > > > become
> > > > RAM bandwidth bound and performance plummets. Don't expect that
> > to
> > > > happen before
> > > > ratios like 1023/1024 or so on your x86.
> > > >
> > > > In these cases, just like in the finely adjustable ratio cases,
> > an
> > > > arbitrary
> > > > ratio resampler becomes the method of choice – but even then,
> > you'd
> > > > often try to
> > > > get "as close as feasible" to the target rate with a rational
> > > > resampler, and then
> > > > only do the remainder that's really close to 1 with an
> > arbitrary
> > > > resampler.
> > > >
> > > > Best regards,
> > > > Marcus
> > > >
> > > > [1] https://dsp.stackexchange.com/questions/31066/how-many-taps
> > -does-an
> > > > -fir-filter-need#31077
> > > >     with δ_1 = 10^-2, δ_2 = 10^-6, and the transition width
> > half an
> > > > alias distance,
> > > >     i.e. f_s/50
> > > > On Tue, 2018-05-29 at 14:37 +1000, Carlo Manfredini wrote:
> > > > > Thanks, that works well.
> > > > > I'm pleased to be able to use the RR, and am using the
> > default taps.
> > > > >
> > > > >
> > > > > On 29 May 2018 at 10:07, Linda20071 <address@hidden>
> > wrote:
> > > > > > Use the rational resampler module (12/25). Decimation 25;
> > interpolation: 12
> > > > > >
> > > > > > On Mon, May 28, 2018 at 7:44 PM, Carlo Manfredini <carloman
> > address@hidden> wrote:
> > > > > > > Hi,
> > > > > > > I wish to transfer continuous data between two devices
> > operating at these two rates:
> > > > > > > 100kSps and 48kSps
> > > > > > > I would appreciate some suggestions as to the "best "
> > method or resampler to use.
> > > > > > > I imaging the RR is not useful here.
> > > > > > > Im thinking some fractional resampler is best.
> > > > > > > Since these rates are quite low I imagine processing load
> > is not an issue.
> > > > > > >
> > > > > > > Also, how does one select the filter taps required ? Are
> > there some tutorials or "rules of thumb" I can follow ?
> > > > > > >
> > > > > > > Thanks for hints.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Discuss-gnuradio mailing list
> > > > > > > address@hidden
> > > > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Discuss-gnuradio mailing list
> > > > > address@hidden
> > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> > >
>
>