discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] how to implement auto-correction of sample rate i


From: Artem Pisarenko
Subject: Re: [Discuss-gnuradio] how to implement auto-correction of sample rate in flow graph ?
Date: Fri, 13 Dec 2013 00:24:50 -0800 (PST)

After several days of hard work I figured out what's wrong, and finally
realized how this task should be solved properly. I generalized it in such
way, that it could solve similar problems experienced by anyone who
connecting multiple hardware clocked blocks in single graph (aka, "The
two-clock problem", as named here:
http://lists.gnu.org/archive/html/discuss-gnuradio/2010-05/msg00117.html).
My solution introduces interface enhancement for sources and sinks and, as
such, requires modification of existing blocks in GNU Radio source tree. So
I would like to get feedback from maintainers before I start to prepare my
contribution.

Basic idea is simple:
1. Source/sink estimates its current buffer level and buffer size each
work() invocation and reports values outside via asynchronous message
interface.
2. Special block inserted between source and sink receives messages from
them, joins values in single pseudo-buffer, filters jitter and implements
control loop: calculates deviation from 50% and corrects samples stream by
adding duplicated samples or removing samples depending on deviation sign.

Pros:
- It works automatically and doesn't depend on clocks skew value, sample
rate and other resampling blocks in graph.
- It doesn't depend on (unknown) intermediate buffers underlying in OS or
buffers between blocks, they affect only stream start-up performance, and
this can be tuned via block configuration. For example, my virtual machine
adds "invisible" ~250ms audio buffer/latency (actually it can be seen from
large difference between ALSA buffer size value and value returned by
snd_pcm_delay()).
- Special block may be tuned (or implemented as different blocks) to adapt
for various clock skew profiles, jitter profiles, etc.
- Unlike timestamp-based solutions it robust and flexible enough to support
various sources and sinks.

Cons:
- It distorts signal heavily at large skew between clocks.

I wonder why nobody did it already.
Please, comment on.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/how-to-implement-auto-correction-of-sample-rate-in-flow-graph-tp45268p45337.html
Sent from the GnuRadio mailing list archive at Nabble.com.



reply via email to

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