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

[Artem Pisarenko]

Hi Marcus,

Everything you said I'm already thought about during last days and finally
came to conclusion, that buffer estimation model is the only reliable (it
solves issue directly by its nature) and universal one (many drivers provide
required functions in their API). Since it involves control loop (i.e. have
feedback), it will compensate all factors you mentioned on large time
scales. Of course, its parameters should be tuned to given system to
maintain it in stable state, at least. No matter, how many intermediate
buffers exists between hardware source endpoint and hardware sink endpoint
(including GR scheduler ones) and how they handled by system. All of them
linked in one chain. Ideally we should combine all of them in single one
large buffer and estimate its filling to get almost precise results
(influenced by jitter only). In practice, software API allows estimate only
some of them, but this is not problem. It just adds unknown offset of
"buffer fallthrough" appearing at start-up (after source block prebuffered
50% and started streaming). Control loop will detect sudden underrun and
will start injecting additional samples in data stream. Finally these
"unknown" buffers will be filled up and system achieve stable state (finish
of start-up phase). How long it will take ? Depends on these buffers sizes
and filter coefficient of control loop algorithm. It's also possible to tune
it with user-defined parameters (filter coefficient and "buffer offset") to
get fastest start-up at given system.


Sylvain Munaut-2 wrote
> 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.

Hi,
Agree, but it's not critical now. Since these corrections expected to be
infrequent, they will not break signal very much. (In audio signal they even
aren't audible to human ear.) I'm going to get system to work first, leaving
tunings at very end.



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