Hi Marcus, > sorry, please believe me, no-one meant to upset you. I'm a bit surprised > you're taking this so personally!
I'm pretty sure nobody wanted to upset me ! But apparently nobody is interested to make the Jack interface work as intended, not even its author... > Anyway, how do you estimate the sample rate offset? Buffer fillage > derivative? As you said, the problem is not lacking a resampler (in > fact, the GNU Radio PFB resamplers are almost too good for this), or the > CPU to run it, but to know what your sound cards are doing... See <http://kokkinizita.linuxaudio.org/papers/adapt-resamp-pres.pdf> and <http://kokkinizita.linuxaudio.org/papers/adapt-resamp.pdf> Between the two incoherent domains there is a buffer and a resampler. The resampler is adjusted so that the average number of samples 'in the pipeline' is constant. The problem is finding a reliable and noise-free estimate of that number. At both ends we don't have a clean continuous stream, but samples are written and read in blocks, and the timing of those write and read operations can be irregular. The solution is to have a delay-locked-loop (DLL) at either side to remove measured timing jitter. This provides a continuous mapping of time to the number of samples written and read. The difference between the two is average number of samples in the buffer, which is compared to a target value. The filtered difference then controls the resampling ratio. 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) _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
