Hi Benny,
On 03.10.2017 19:48, Benny Alexandar wrote: > By using the PC clock, and calling set time now with > the current PC time before scheduling streaming. This will make the USRP > tick counter roughly match the PC clock. Yeah. But that doesn't help at all, since clock recovery of any digital receiver will give you samples resampled to the transmitter's clock... Anyway, notice how you say "roughly". Now, compare that "roughness" to the "roughly the same" transmitter and receiver audio clock. You're at least in the same order of magnitude here, and my point is that by introducing yet another clock into this (the abyssimal bad PC clock), you're making things way worse than they need be, and atop of that, unnecessarily complicated. > > usrp_source->set_time_now(uhd::time_spec_t(secs, micros, long(1e6)); > > Then use the Jack audio clock and maps this audio clock to system one . Again, I don't see where you see the audio device clock in your system. I'd be very thankful if you could explain **that** to me, since well, there's no clock line between my sound card and my CPU. > > At the input side USRP decides the input rate, slave the audio to this > rate. aaaand we're stating the original problem again. We don't know any of these rates relative to any other of these rates. Best regards, Marcus
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
