On 08/05/2013 09:48 PM, Stephen wrote:
On 8/5/2013 8:17 PM, Marcus D. Leech wrote:
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".
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
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.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
