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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
