Hello Matt,
I went back and tried your suggestion of setting the transmitter at 50kbps and
keeping the ffmpeg stream at 45 kbps. This actually gets rid of almost all the
latency buildup however the problem is that the transmit GRC script running the
USRP is now consistently giving underruns errors. This is causing the received
video signal to have a lot of distortions.
It seems like the video stream rate has to be lower than the transmit/receive
rate like you suggested but then this causes a problem because the USRP seems
to not get the samples fast enough to avoid underruns. I'm not sure if there
even is a solution to this that I could easily implement with GRC.
Thanks again, Tom
________________________________
From: Tom Hendrick <sdtom...@yahoo.com>
To: Matt Ettus <m...@ettus.com>
Cc: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>; "j...@ettus.com"
<j...@ettus.com>
Sent: Wednesday, January 23, 2013 10:40 AM
Subject: Re: [Discuss-gnuradio] Unknown cause of Latency with USRP
Hello Matt,
The ffmpeg encoder is set to 45 kbps bitrate and the transmitter/receiver is
set to about 45 kbps as well.
The ffmpeg encoder doesn't converge at 45 kbps exactly, but it comes close.
The signals are sampled at a pretty high rate of 500 kHz and the GRC scripts
resample at 1 MHz so the USRP is run at 1MS/s rates.
Thank you, Tom
________________________________
From: Matt Ettus <m...@ettus.com>
To: Tom Hendrick <sdtom...@yahoo.com>
Cc: "j...@ettus.com" <j...@ettus.com>; "discuss-gnuradio@gnu.org"
<discuss-gnuradio@gnu.org>
Sent: Wednesday, January 23, 2013 10:34 AM
Subject: Re: [Discuss-gnuradio] Unknown cause of Latency with USRP
What is the bit rate of the source and what is the bit rate of the data
transmission?
Matt
On Wed, Jan 23, 2013 at 10:32 AM, Tom Hendrick <sdtom...@yahoo.com> wrote:
Hello Josh,
>The transmitter sends data when there is enough to fill a packet. The packets
>are flushed about every 200msec consistently. The ffmpeg encoder seems to
>have a continuous output that is pretty steady since it is encoding webcam
>images at a pretty reasonably constant bitrate with the settings I applied.
>
>When I look on the oscilloscope output of the USRP tx board, the stream shows
>no gaps or pauses at all and the packets look spaced properly in time as if I
>had written the transmitter output directly to a file.
>
>Are the solutions you recommended something I can try implementing with GRC
>(for instance throttle or the gr_block api)? Making the external
>modulator/demodulator work in a burst type mode is something I probably don't
>know how to do. I know how to run the
modulator/demodulator code but I didn't develop it. The only thing I can
think of adjusting is the amount of data blocks inside a packet. I can
increase or reduce that number and that would increase/decrease the time
duration between flushing of packets.
>
>Thanks very much for your help, Tom
>
>
>
>
>
>
>________________________________
> From: Josh Blum <j...@ettus.com>
>To: discuss-gnuradio@gnu.org
>Sent: Tuesday, January 22, 2013 10:54 PM
>Subject: Re: [Discuss-gnuradio] Unknown cause of Latency with USRP
>
>
>
>>
>> I appreciate any advice. I'm out of ideas and have searched a lot on
>> latency related to GNURadio and most of the latency I've read up on
>> seems to be in the microsecond to millisecond ranges.
>>
>> Thanks very much, Tom
>>
>>
>
>Does the application that produces transmit samples send bursts of
>samples only when there is data to send, or is the transmitter always
>being fed?
>
>I ask because gnuradio can potentially have a lot of buffering, and if
>your transmit app is producing continuous samples or producing samples
>faster than the rate consumed, the buffering will just become full, and
>it will take buffer_size/sample_rate seconds to see a change occur
>through the pipeline.
>
>If this is the issue, I recommend some kind of bursty transmission.
>Some neat examples of this in precog
>https://github.com/jmalsbury/pre-cog/wiki
>
>If you need to continuously transmit, you might want to maintain a
>window of buffering where the application throttles back production of
>samples. One way to do this would be to simply use the consumption of rx
>samples to throttle the production of tx samples.
>
>Another alternative would be to use the gr_block api to shrink the
>buffer size of each block in the transmit chain -- to minimize the
>capability of gnuradio buffering data -- if the app must rely on
>backpressure from gnuradio
>
>-josh
>
>>
>> _______________________________________________ Discuss-gnuradio
>> mailing list Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>_______________________________________________
>Discuss-gnuradio mailing list
>Discuss-gnuradio@gnu.org
>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>_______________________________________________
>Discuss-gnuradio mailing list
>Discuss-gnuradio@gnu.org
>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
