Forum: GNU Radio question about overruns with simple flowgraph

B9dcf163c294a5adbe3552d60497e374?d=identicon&s=25 Stephen (Guest)
on 2013-08-06 02:55
(Received via mailing list)
Hi,

I have a simple FM broadcast receiver flowgraph in c++ that causes
overruns. I'm using a B100 with a wbx daughter board. The flowgraph is

usrp source -> lowpass filter -> quad demod -> deemphasis -> audio lp
filter -> constant multiply -> audio sink

The sample rate is 250K. It works but after a couple of seconds the
overruns start. I've used much more complicated flowgraphs than this
with much higher sampling rates with out overruns. Looking at the cpu
utilization shows each core at less than 5%. Would anyone have any
suggestions for what to look at that could be causing the problem?

thanks,
stephen
0f670021207b3329243056244633dcad?d=identicon&s=25 Nick Foster (Guest)
on 2013-08-06 03:01
(Received via mailing list)
On Mon, Aug 5, 2013 at 5:53 PM, Stephen <ctx50026@centurytel.net> wrote:

> overruns start. I've used much more complicated flowgraphs than this
> with much higher sampling rates with out overruns. Looking at the cpu
> utilization shows each core at less than 5%. Would anyone have any
> suggestions for what to look at that could be causing the problem?
>

It's been called the "two-clock" problem. Basically, your soundcard's
clock
is decoupled from the USRP's clock, and neither is ideal -- they have
error. As they drift apart either the audio clock will run slower
(producing overruns) or faster (producing underruns).

Here's an older discussion of the same issue.
https://www.ruby-forum.com/topic/209464

A couple of seconds seems pretty fast, however. Make sure you're
resampling
the audio to a rate which is actually supported by your soundcard.

--n
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2013-08-06 03:19
(Received via mailing list)
On 08/05/2013 09:00 PM, Nick Foster wrote:
>
>
> A couple of seconds seems pretty fast, however. Make sure you're
> resampling the audio to a rate which is actually supported by your
> soundcard.
>
> --n
>
The two-clock problem tends to manifest as the occasional "click" or
occasional 'O'.

But if the rates between USRP source, and audio sink are significantly
mis-matched, you end up with overruns very quickly, since buffers will
   start to fill up to exhaustion, since the sink isn't taking samples
as fast as they're being produced.

There's no "magic" rate-adaptation in Gnu Radio.  If you have a filter
block that is decimating down to, let's say, 50kHz, and then feed it
into
   an audio sink that's expecting data at 48kHz, things will get stuffed
pretty quickly.  Just because a (hardware) sink is expect data at
   some rate, doesn't mean that Gnu Radio automatically "tweaks" the
flow graph to deliver data at that rate.  Gnu Radio is a streaming
   architecture, it doesn't actually inherently "know" about sample
rates, so you have to take care of decimating/interpolating data streams
   so that things "match".


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
B9dcf163c294a5adbe3552d60497e374?d=identicon&s=25 Stephen (Guest)
on 2013-08-06 04:02
(Received via mailing list)
On 8/5/2013 8:17 PM, Marcus D. Leech wrote:
> occasional 'O'.
>   some rate, doesn't mean that Gnu Radio automatically "tweaks" the flow
> graph to deliver data at that rate.  Gnu Radio is a streaming
>   architecture, it doesn't actually inherently "know" about sample
> rates, so you have to take care of decimating/interpolating data streams
>   so that things "match".
>
>

Ahhhh, now I see. I am getting frequent 'O' and audio clicks and pops. I
had played with the various rates till I got the final audio decimation
very close to an integer value but not quite. The integer value used was
a little lower than needed. I adjusted things some more and got a set of
rates that resulted in an integer decimation for the audio lp filter and
that fixed the problem.

The link to the previous discussion was interesting.

thanks, guys
stephen
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2013-08-06 04:05
(Received via mailing list)
On 08/05/2013 09:48 PM, Stephen wrote:
>> The two-clock problem tends to manifest as the occasional "click" or
>> pretty quickly.  Just because a (hardware) sink is expect data at
> a little lower than needed. I adjusted things some more and got a set of
> rates that resulted in an integer decimation for the audio lp filter and
> that fixed the problem.
>
> The link to the previous discussion was interesting.
>
> thanks, guys
> stephen
>
>
>
I tend to use the fractional interpolator--you can get exact rate
matching that way.  It doesn't seem that expensive, particularly when I
use it at the
   "low speed" part of the graph near the audio subsystem.
B9dcf163c294a5adbe3552d60497e374?d=identicon&s=25 Stephen (Guest)
on 2013-08-07 03:09
(Received via mailing list)
>>
> I tend to use the fractional interpolator--you can get exact rate
> matching that way.  It doesn't seem that expensive, particularly when I
> use it at the
>   "low speed" part of the graph near the audio subsystem.
>

I tried that and it worked. But it adds a small amount of hiss. I also
tried the fractional resampler. It added a lot of hiss and a high pitch
whine. The polyphase arbitrary resampler added a more hiss than the
fractional interpolator but less than the fractional resampler.

stephen
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2013-08-07 03:17
(Received via mailing list)
On 08/06/2013 09:07 PM, Stephen wrote:
> stephen
>
If you're downsampling, you do need to make certain that the bandwidth
of your incoming signal (regardless of its rate) is appropriate for
   the final bandwidth after the resampler.



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
F18b7b61dfbfe46c7af3cbcbda568c4f?d=identicon&s=25 Vanush Vaswani (Guest)
on 2013-08-08 18:05
(Received via mailing list)
Has there been any effort in using PTP to solve the two-clock problem
(like
Audinate's Dante)?
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2013-08-08 19:06
(Received via mailing list)
On 08/08/2013 12:03 PM, Vanush Vaswani wrote:
> Has there been any effort in using PTP to solve the two-clock problem
> (like Audinate's Dante)?
>
The two-clock problem exists due to the fact that the two *hardware*
clocks involved here -- the audio subsystem, and the USRP aren't
   locked to each other, and aren't at exactly, precisely, the rate you
think they are (the nature of oscillators).

Clock-skew (between source and sink) tends to get "absorbed" in
buffering, but since buffering is a finite resource, occasionally
leading to the audio
   subsystem saying "guys, I can't accept any more samples at the
moment, my buffers are full".  The way to "solve" this problem is to
have a control-loop
   that allows you to fine-tune the rate that samples are delivered to
the sink -- you need a "speed up a bit/slow down a bit" control message
that occurs
   before things are about to get ugly.


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
B9dcf163c294a5adbe3552d60497e374?d=identicon&s=25 Stephen (Guest)
on 2013-08-11 23:53
(Received via mailing list)
On 8/6/2013 8:15 PM, Marcus D. Leech wrote:
>>
>> stephen
>>
> If you're downsampling, you do need to make certain that the bandwidth
> of your incoming signal (regardless of its rate) is appropriate for
>   the final bandwidth after the resampler.
>
>
>
so when is it more appropriate to use a rational resampler vs a
polyphase arbitrary resampler vs a fractional resampler vs a fractional
interpolator ?  Does the processing load differ grately between them?
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2013-08-12 00:17
(Received via mailing list)
On 08/11/2013 05:52 PM, Stephen wrote:
>
> so when is it more appropriate to use a rational resampler vs a
> polyphase arbitrary resampler vs a fractional resampler vs a fractional
> interpolator ?  Does the processing load differ grately between them?
>
The only way is to try them all, *in your environment, with your flow
graph*, and measure.



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.