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

[Artem Pisarenko]

Hi Marcus,


> your citing that thread of 2010 clearly shows you still didn't get the 
> problem. Point being: If your source has a different speed than your 
> sink, you'll need resampling in Software. This has nothing to do with 
> synchronizing. I won't further elaborate on this.

I don't understand what I said wrong again ? This is exactly what my
proposal is - resampling. I know, that problem is in hardware. And I know
that ideal solution is synchronization (again, in hardware, of course). My
proposal is just alternative cheap solution for those cases, when
synchronization is not possbile (for whatever reasons).


> 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.

You misunderstanded me again. I talked about hardware I/O buffers. I
mentioned GR buffers only because they are part of total buffers chain from
source hardware to sink hardware and, as such, they affect data propagation.
But my solution doesn't rely on them in any way.

My proposal just solves classic problem, when source and sink have same
sample rate nominally (e.g. 48000) but actual rates are varying (e.g. 47999
vs 48001) due to temperature ranges and drifting. If your source and sink
have totally different rates then, of course, you should use rational
resampler available in standard blocks collection of gnu radio, but
additionally you may insert my block which will finally make speeds match
precisely. (Of course, it's not strictly true, but I hope you understand
what I mean.)
Why don't I want add/remove samples ? Any resampler actually does it.
Final purpose of this solution is just eliminate buffer over/under-runs when
streaming data between non-synchronized hardware. If you like watch
disturbing 'aU'/'aO'/'uU'/'uO' output in console (btw, it streamed to
stderr, so it considered to be errors) and found my proposal useless, I have
nothing to say here. In my case there are large latency, so I have
additional bonus to console output: streaming interruption for a long
duration in order to prebuffer and restore streaming.



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