Hi Fons, >The only time that would make sense would be the >timestamp at the A/D converter of the RF sample that in some way >corresponds to the start of the compressed frame. And even that >assumes that there is simple linear relation between the RF samples >and audio samples.
Yes, thats right. But now the problem is RF samples are captured by USRP and is passed to PC for further processing. So, if USRP timestamps the RF block of samples it will be based on a different clock. For example the timer used in USRP is 2MHz counter, when it is received at PC side clock conversion is required to match the PC 1 MHz counter. Can this conversion affect the timestmaping at PC side because of round off error? RF block duration is directly propotional to audio frame durations. 100ms of RF block duration will corresponds to 100ms of audio. Otherwise it won't be continuous audio streaming. This is my understanding, please correct if I'm wrong. -ben ________________________________ From: Fons Adriaensen <f...@linuxaudio.org> Sent: Thursday, November 10, 2016 2:56:50 AM To: Benny Alexandar Cc: Marcus Müller; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem) On Wed, Nov 09, 2016 at 05:12:25PM +0000, Benny Alexandar wrote: > So the logic is whenever an audio compressed frame arrives at the audio codec, > it is timestamped with the current time (Ti) and after uncompressed each audio > frame blocks (24ms) is timestamped by adding 24ms ( Ti + ( frame_no * > frame_duration )), > where Ti is the start time and frame_no is the decoded uncompressed frames > ranges from > 0 to n and frame_duration is 24ms. That doesn't make much sense, for at least two reasons. First, the time when a compressed frame arrives at the codec has no meaning. At that point the signal is just data stored in memory, not a physical one. The only time that would make sense would be the timestamp at the A/D converter of the RF sample that in some way corresponds to the start of the compressed frame. And even that assumes that there is simple linear relation between the RF samples and audio samples. Now that doesn't mean that such timestamps can't be used. But you can't use them in the naive way you describe. Second, if you read the timer once and then just add the nominal 24ms for all following timestamps, you don't get any information about the data rate at all. Simple reason is only the first timestamp contains any new information, all the others are redundant because they can be computed from the first. But maybe I misunderstand that part of your scheme. > ... After some N seconds this accumulated value is averaged by dividing > by N sec. So I get the drift in sampling rate in terms of samples. > Then all I need to do is slow down or speed up the sampling rate based > on which side the drift is. You'd need to do this continuously. A single correction can't be perfectly accurate, and any remaining error is integrated w.r.t. time and will grow without bound. And you can't assume the sample rate ratio is fixed, it will drift as well. > Is it possible to change the sample rate of ALSA by drift amount ? On a few professional (and very expensive) audio cards allow continuous control of the sample rate, e.g. RME's MADI interfaces. 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
