Re: [Discuss-gnuradio] how to implement auto-correction of sample rate in flow graph ?

[Marcus Müller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Sylvain,

Ok, I see the point here and I agree that it would be nice if a block
was notified of a "filling output buffer chain" in advance. (you
could, however, use the noutput_items parameter or nitems_written()
together with some system clock to get an idea of what is being consumed)

However, you explained the problem very nicely: Your hardware does
something strange, e.g. repeating samples, when it goes too slow/fast.
The only way to actually account for that is the monitoring of the
sink sampling clocks relative to the source sampling clock. However,
that's something you can't do in software, you need some hardware
feedback to give you a reasonably exact estimate of the frequency
offset, since you don't see the output of your hardware sink (usually).
For different soundcards there might (and might not) exist some method
to find out how fast a playback buffer got used up; this is very
hardware-dependent and not easily unified in software, especially
since in this case timing offsets in the order of microseconds are
relevant and if your feedback mechanism incorporates context switches,
async messaging and computation, you won't be getting reliable results.

Basically: If your hardware is "bad" by means of drifting/wrong
clocks, and you can't monitor your output, you'll be having a bad day.
This is an inherent problem of SDR, I reckon, and from my point of
view the only solution would be constraining hardware clocks of sinks
and sources using a common master clock (that's what most SDR
peripherals do, therefore), or monitoring the sink output using the
same source clock (which is just another incarnation of controlling
the sink clock using the source clock).
In software architectures like GR that rely on "large" buffers to
enable normal operating systems to run the SDR, I guess you will have
a hard time figuring out actual clock deviations just by measuring
buffer filling; there's just so much more than just the sink clock
going astray that could happen which will make things look like
latency was building up. Again: Using GR you usually try to ignore the
fact that computation may (and will) take different amounts of time at
different points in time, even for the same block, and rely on the
scheduler to call the linked blocks' work()s with fitting parameters.
Measuring the amount of data that passes through software buffers
won't therefore help you much when measuring the sampling speed of a
hardware sink, or only on very large time scales.

Greetings,
Marcus
On 13.12.2013 11:48, Sylvain Munaut wrote:
> Hi,
> 
> 
>> Blocks shouldn't care for their own buffer "fill"; that's the job
>> of the runtime and GR does this fairly well, to be honest. Your
>> Virtual machine audio related problem is hardly a proof of
>> shortcomings of this concept.
> 
> I don't agree with this.
> 
> Blocks should be able to monitor the buffer level to act in
> consequence.
> 
> A real world example : - RF front end gets samples - Demod process
> to compressed audio frames - Sends to codec to convert to audio -
> Sends to audio card for playback
> 
> Now in this system you have two physical unrelated clock source;
> The RF sampler and your audio card. All the samplerate relationship
> in the flow graph would be adjusted for their nominal speed but of
> course they won't be in perfect sync.
> 
> Now if your audio card is a bit faster, it will run out of samples 
> from time to time. It might replay automatically the last one and
> you might not hear it. But if your audio card is a bit slow, the
> buffer in front of it will slowly fill up and you'll have a rising
> latency (and finally drop samples when it fills up).
> 
> Now a real world vocoder I'm working with right now deals with
> this problem by having variable length audio frames. When I get one
> frame of encoded audio, I can ask the codec to generate between
> 19.5 ms to 20.5 ms of audio (for a nominal 20ms frame) and it's of
> course much better than dropping/repeating samples blindly.
> 
> But to be able to use this, the codec block needs to be able to 
> monitor the output buffer level so it can try to maintain it at a
> good level.
> 
> 
> Cheers,
> 
> Sylvain
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSqvhOAAoJEAFxB7BbsDrLTvQH+wQi8ayhT5H4pXCTjxMgHkZR
gSvbZAW6eZ5TLl0RSDyWtdyXwjSlNiH669r1q8i7zaq6H32395SjwkYYPyuAumRU
N4qFS76AcvZLcCCuzuvC6fPFlbu2RTFtGINC9Buy9K2W2jwiOWLMYwKJ6Idenl8t
vjKB83Epn/vue3iIclvyijgMm6uF0M/+SUS8AFe2SAmPwKc3tHZquwnodiPTIE+q
sLykZfcirU8Ws9ibb3tReRW5pEi8b8Lt5rLJHtLJmUouiyqWcvpghypUy5MIbGin
pTlxH8eFVaqPqANC+vwEzV6lOjDz11i7YRAUDwq7Ex7U4YVXqU46/tLL95LA9r0=
=j4Q3
-----END PGP SIGNATURE-----