On Thu, Nov 10, 2016 at 04:17:25PM +0100, Marcus Müller wrote: > > RF block duration is directly propotional to audio frame durations. > > 100ms of RF block duration will corresponds to 100ms of audio. > > no! And that's exactly the problem. In theory, it should be the way, but > because neither the RF clock nor the audio DAC rate are exactly what > they should be, this is not inherently true. And that's what Fons is > trying to solve.
Well, assuming constant bit rate audio coding, on average T seconds of RF will correspond to T seconds of audio. But that is besides the question. We have codec -> [ buffer -> resampler ] -> audio HW. where [...] is the audio sink block. The buffer is *an internal part* of the audio sink, and *not* the one that gr provides to connect codec and audio sink. The resamping control loop will try to have on average a constant number of samples in this buffer. For this it needs timing info on both the incoming and the outgoing blocks of data, using the same clock for both. The clock used on the audio HW side is part of the audio sink block, and the same must be used for buffer writes. That means that only the audio sink block can do meaningfull timing of the buffer writes, and any other info provided by upstream blocks is useless. That's also why the buffer is part of the audio sink. In other words, on the write buffer side the timing is that of the audio sink work(), and on the read buffer side the timing is that of the audio driver (or jack) callback. No external timing info is needed. 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
