discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing
Date: Tue, 3 Oct 2017 21:32:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]