# Buffers and Sample Rates

**URL:** <https://www.ruby-forum.com/t/buffers-and-sample-rates/242364>\
**Category:** GNU Radio\
**Created:** [June 18, 2015, 9:52pm UTC](https://www.ruby-forum.com/t/buffers-and-sample-rates/242364 "2015-06-18T21:52:31Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\
**Post date:** [June 18, 2015, 9:52pm UTC](https://www.ruby-forum.com/t/buffers-and-sample-rates/242364/1 "2015-06-18T21:52:31Z")

</div>

Hi all,

I’m working on a system that has hardware defining an input rate and  
hardware defining an output rate. This is a data based system, so I  
can’t  
afford to lose any bits, which implies sample rate changes have to be  
exact.

For example, if data is being input at 2.4 ksps and the USRP outputs  
data  
at 468.168 ksps, unless my intermediate sample rate changes produce a  
perfect mapping between the two rates, I can expect a buffer under or  
overflow eventually, which would produce problems.

One solution to this problem, would be to use an arbitrary resampler  
before  
the USRP, that consists of a PLL dynamically changing the sample rate of  
the arbitrary resampler based on how full it’s output buffer is. If the  
buffer is above half full, decrease your sample rate, if the buffer is  
below half full, increase your sample rate.

Now the question. I assume I’m not the first person that has needed to  
do  
something like this, is there a built in mechanism to handle this  
problem  
already or do I have to create the feedback loop structure myself? I’d  
rather not re-invent the wheel.

v/r,  
Rich

---

<div class="post-metadata">

**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\
**Post date:** [June 18, 2015, 9:54pm UTC](https://www.ruby-forum.com/t/buffers-and-sample-rates/242364/2 "2015-06-18T21:54:51Z")

</div>

We call this the “two clock problem”. This is something people  
(including  
myself) have been talking about implementing for ages. There’s nothing  
available in GNURadio right now to do this.

–n

On Thu, Jun 18, 2015 at 12:51 PM Richard B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\
**Post date:** [June 18, 2015, 10:03pm UTC](https://www.ruby-forum.com/t/buffers-and-sample-rates/242364/3 "2015-06-18T22:03:02Z")

</div>

It’s not unique to modern DSP systems, either.

When we put together a bit-regenerating repeater for 56kbit packet “back  
in the day”, we had to design an elastic hardware buffer to “soak up”  
slight differences in RX and TX clocks–the RX bit clock was from the  
remote station, and TX bit-clock was ours. The elastic buffer worked OK  
over the modest frame sizes we were using, but couldn’t soak up skew  
indefinitely…

On 2015-06-18 15:53, Nick F. wrote:

> > For example, if data is being input at 2.4 ksps and the USRP outputs data at  
> > 468.168 ksps, unless my intermediate sample rate changes produce a perfect mapping  
> > between the two rates, I can expect a buffer under or overflow eventually, which  
> > would produce problems.
> 
> * * *
> 
> Discuss-gnuradio mailing list  
> [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
> [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) [1]

Links:

---

<div class="post-metadata">

**Author:** ![reback](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b5ac83/32.png) [@reback](https://www.ruby-forum.com/u/reback)\
**Post date:** [June 18, 2015, 10:14pm UTC](https://www.ruby-forum.com/t/buffers-and-sample-rates/242364/4 "2015-06-18T22:14:08Z")

</div>

Alright thanks for the feedback. It sounds like I have some work to do.

v/r,  
Rich