Re: [Discuss-gnuradio] GRC pure FSK with USRP1 board sampling troubles

[ikjtel]

Nick Foster wrote:
> In the "real world" this problem is usually solved by
> dynamically resampling the audio stream at a rate controlled
> by a feedback loop responding to the observed clock mismatch.

I have a USRP1 with a BasicTX daughterboard.  When transmitting,
what is the proper method in a GNU Radio app for "observing" the
USRP, such that underrun (uUuUuU) errors are guaranteed not to
occur? [corollary: neither do we want queues to build up]

We're of course assuming here that the CPU has plenty of power,
that the TX sampling rate is completely reasonable, etc., etc.

We're also suggesting that our app might not necessarily have on
tap an infinite number of samples for immediate shipment to the
USRP at all times.  (Think: just-in-time)...

We're assuming that the design specs for our app say that:
"USRP underruns are totally unacceptable"
 (is this a realistic goal to have in the "real world"?)

Is this capability available at all or is it hardware-dependent?
Or perhaps driver-dependent (UHD or whatever)?

> If your ALSA-fu is strong and you have some free time, though,
> it'd be super awesome to see this part taken care of. I've been
> meaning to tackle this in the audio sink for a while now, but
> put it off.

There are at least two cases I've been looking at which wouldn't
benefit (at least directly) from this, unfortunately....
1) audio sink is only half of it, audio source is also needed
2) All the VOIP stuff seems to use a standard sample rate of 8,000

If GNU Radio does try to take a stab at the two-clocks problem
is it possible to generalize the solution beyond just ALSA users?

Thx & 73 de KA1RBI

Max