Question about overruns with simple flowgraph

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

On Mon, Aug 5, 2013 at 5:53 PM, Stephen [email protected] 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

On 08/05/2013 09:00 PM, Nick F. 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 L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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.

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

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 L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

On 08/08/2013 12:03 PM, Vanush V. 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 L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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?

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 L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

Has there been any effort in using PTP to solve the two-clock problem
(like
Audinate’s Dante)?