Please find the attached block diagram of how the control loop is placed in
the whole system.
In the figure the first block is the RF IQ acquisition block which samples
the RF samples and put a timestamp. It is then passed on to channel and
audio decoder and finally reaches the audio sink. Audio sink does the audio
playback on fragments of audio.
The audio control loop module has two inputs and one output. The inputs are
for sending the timestamp of write side and read side. In this case the
write side is RF capture and read is from audio sink. Note these two time
stamps are coming from different clock, the RF capture uses PC CPU clock
where as the audio sink has sound card clock. The output of audio control
loop is used to control the re sampler which sits in between audio decoder
and audio sink.
AudCtrlLoop.JPG
<http://linux-audio.4202.n7.nabble.com/file/t2646/AudCtrlLoop.JPG>
-ben
Fons Adriaensen-3 wrote
On Sat, Sep 16, 2017 at 10:17:04PM -0700, benravin
wrote:
I'm facing a timing jitter which happens
periodically due to some
interrupt,
which is causing the task to be delayed. Since this happens periodically,
it
is indeed a slow varying timing jitter, for example every 400ms, the
timing
deviation is in the order of few ms ( 4-6ms). This is not getting
filtered
out by DLL, and results in a slow varying oscillations which never dies.
Any way to identify and limit these timing jitters and not to take any
action on drift correction by DLL ?
It's impossible to say anything about this if you don't provide
numbers. How big is the resulting resampling ratio variation ?
If a few ms jitter leads to anything perceptible then your DLL
and/or resampling control loop are not dimensioned correctly,
or there is another basic problem with your design.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
_______________________________________________
Linux-audio-dev mailing list