Two Clock Drift Compensation, howto?

Dear all!

When I have multiple hw audio (or other) sources and sinks gnuradio is
suffering from the “two clock problem”.

From the docs I have read, one means to mitigate against under- or over-
runs is to have the sender always be a little faster.

While I understand that this will help keep the sink always filled it
will not avoid buffer under runs, or am I misunderstanding something?

Also the only way for the source to keep up is to throw away samples at
times.

Has anyone came up with an idea of how this problem could (should) be
addressed in a proper way in gnu-radio? (I mean without changing hw.)

From a little test set up I have seen that I could program a sink and a
source, referencing a common buffer. The buffer level (a smoothed
version) could be the driving variable to a dynamically programmed
sample rate converter that is set up so as to keep the buffer level
constant.

Is this a too hakish attempt to address the problem?

Has anyone already tried this?

Is there a more straight forward way, i.e. using a regular input-output
module?

I am thankful for any hints or comments.

Roland


_ _ | Roland Schwarz
|)( |
| __) | mailto:[email protected]
________| http://www.blackspace.at

Hi Roland,

I have used the method you suggest in the distant past to match sample
rates of audio hardware with nominally equal but independent clocks. I
found it worked “ok” as long as the resampler you are using can handle
small dynamic offsets ie: +/- 0.1Hz without noticeable artifacts. The
FIFO
used to measure the difference in rate also adds some latency.

On Tue, Apr 7, 2015 at 7:34 AM, Roland Schwarz
<[email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs