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. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
