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