[USRP-users] [Discuss-gnuradio] continous Tx voice transmission
Marcus D. Leech
patchvonbraun at gmail.com
Wed Mar 6 10:53:06 EST 2019
On 03/06/2019 10:48 AM, Ian Buckley via USRP-users wrote:
> The elegant architectual solution (abstracted from GR) is to have a FIFO cross those 2 real clock domains, monitor the fullness and do closed loop sample rate adaption in reaction to the FIFO’s fullness….
> Now I can also think of reasons why that would be tricky to do well in GR.
It's a tad surprising that nobody has done an elastic buffer
implementation for GR.
>> On Mar 6, 2019, at 1:47 AM, franz kurniawan via USRP-users <usrp-users at lists.ettus.com> wrote:
>> Hi all,
>> i have struggling for couple of weeks in my AM transmitter project.
>> i use audio source (alsa) as input and USRP sink (B200mini) as output..
>> i know that this making a "2 clock problem" and it will create either underflow "U" or building latency between microphone (audio source) and resulted radio transmission after several hours of continuous running..
>> i have tried some solutions below but none is working well :
>> * set OK to Block to "No" in audio source to remove clock in audio source.
>> Previously i have modified the source of alsa_source.cc since in the OK to block feature in alsa is ignored in current version of gnuradio. But the problem still persists
>> * using tagged stream to enable the burst mode of USRP. But also the problem still persists
>> * manipulation of resampling rate with below formula:
>> interpolation : int(samp_rate * 1.000)
>> if i make the constant < 1.000 so that the consumer rate will be slightly faster than producer rate, it will lead to repeating "U" , but there is no latency.
>> else if the constant > 1.000 , there will be no "U" , but there will be building latency..
>> So, is there any proper solution to this kind of problem?
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
> USRP-users mailing list
> USRP-users at lists.ettus.com
More information about the USRP-users