Nick F. 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…
- audio sink is only half of it, audio source is also needed
- 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