Hi Benny > > For a) & b) will use the sound card clock and using micro seconds timer. ... that's not a solution, that's the original problem I state.
You don't *get* the sound card clock anywhere in software. If you did, there would be no problem. Respectfully, Marcus On 09/27/2017 10:15 AM, Benny Alexandar wrote: > > >>Could you maybe elaborate how you're planning to solve all a),b),c) > instead of asking for new feedback? > > > > For a) & b) will use the sound card clock and using micro seconds timer. > > And for c) run the decoded PCM through a FIFO buffer this is a local > buffer which is not part of gnu-radio connect buffers, between the > SRC and the play-out stage. The trade-off for this approach of course > is increased latency. > This way any variable work-load length is not going to affect and the > local fifo will have fixed length. > Timing errors needs to be filtered using DLL which is the same used > in JACK. > > -ben > > > > > > ---------------------------------------------------------------- > > > And as also said earlier, I don't believe very much that it will work > that easily, since the CPU clock is a) worse than the typical SDR and > sound card clocks, b) has different resolutions, c) and needs to still > be sufficiently interpolatable for the jittery, > variable-workload-length that GNU Radio has. The point c) is what's > different for Jack internally, because that can work on fixed-length > buffers. > > > This is a comment that you've gotten from me (and by the way, Fons, > too) multiple times now. Could you maybe elaborate how you're planning > to solve all a),b),c) instead of asking for new feedback? > > > > ------------------------------------------------------------------------ > *From:* Benny Alexandar > *Sent:* Wednesday, September 27, 2017 6:50 AM > *To:* Marcus Müller; GNURadio Discussion List > *Subject:* Re: [USRP-users] Audio Control loop testing > > Hi Marcus, > > As said earlier there is no true clock as such. We need to rely on CPU > clock and measure the deviation. The reference clock is the > transmitter time duration between two symbols which is a preset value. > Do you have any suggestions for a *better reference clock* > > -ben > > -------------------------------------------------------------- > > Hi Benny, > > you're, again, missing the core problem: it's hard to measure the time > deviation between two symbols without a better reference clock. And > you don't have that. And thus, we're back at the start of all our > email chain. > > Best regards, > > Marcus > ------------------------------------------------------------------------ > *From:* Benny Alexandar > *Sent:* Tuesday, September 26, 2017 10:56 PM > *To:* Marcus Müller; GNURadio Discussion List > *Subject:* Re: [USRP-users] Audio Control loop testing > > Hello, > > Now the timing of input side is after detecting the start of symbol. > Every symbol will be timestamped and measure the time deviation > between two symbols. > > d = t1 - t0, > where t0 - time of arrival of symbol (n) > t1 - time of arrival of symbol (n+1) > d - time deviation between two symbols. > > D - time duration between two symbols according to digital radio > standards, then error = ( D / d ) - 1 > > Please send your suggestions feedback regarding this approach. > > -ben > ------------------------------------------------------------------------ > *From:* Benny Alexandar > *Sent:* Friday, September 22, 2017 10:26 PM > *To:* Marcus Müller; GNURadio Discussion List > *Subject:* Re: [USRP-users] Audio Control loop testing > > Hi Marcus, > > Please find the attached figure on how the audio control loop will be > placed in > Gnu Radio chain. In the figure the first block is the RF IQ > acquisition block which samples the RF samples and put a timestamp. It > is then passed on to channel and audio decoder and finally reaches > the audio sink. Audio sink does the audio playback on fragments of audio. > > The audio control loop module has two inputs and one output. The > inputs are for sending the timestamp of write side and read side. In > this case write side is RF capture and read is from audio sink. Note > these two time stamps are coming from different clock, the RF capture > uses PC CPU clock where as the audio sink has sound card clock. The > output of audio control loop is used to control the re sampler which > sits in between audio decoder and audio sink.More details on how the > audio control loop will be send soon. > > Please send your feedback regarding this approach. > > > -ben > ------------------------------------------------------------------------ > *From:* Marcus Müller <marcus.muel...@ettus.com> > *Sent:* Tuesday, September 19, 2017 10:47 PM > *To:* Benny Alexandar; GNURadio Discussion List > *Subject:* Re: [USRP-users] Audio Control loop testing > > > Hi Ben, > > >> May I know why not with JACK ? > > From the very same email you're referring to: > > >> (not much sense writing it for the Jack sink, if Jack can already do >> it internally) > Also, >> Here, I need your inputs. > I spent around 5 hrs on input on this topic already. I don't feel like > you need more input, it feels more like you haven't had the chance yet > to understand all the input that there is on the GNU Radio mailing > list. We should also not be having this discussion on usrp-users, as > your approach doesn't involve USRPs directly! > >> Can you please state the requirements. How it has to be in GNU radio >> chain etc. > > Please re-read my previous email. I explicitly say I'm not even > convinced this will reliably work in software. GNU Radio is software. > What about you just start by trying to implement a control loop, and > read as much on theory of discrete-time control systems as you'll need > for this? I'm afraid I can't take that burden off your shoulder if you > want to implement a control loop. It is hard stuff. > > Best regards, > Marcus > On 09/19/2017 10:10 AM, Benny Alexandar wrote: >> Hi Marcus, >> >> Yes its true I couldn' t make much progress on this. Not able to >> find time as I have a full time job. If I remember correctly, you >> mentioned that no-one has implemented audio control loop within GNU >> Radio. And you were suggesting to write it for ALSA and not with JACK. >> >> May I know why not with JACK ? If I need to make it with JACK, GNU >> radio should run as a client and output to JACK input port and >> another client which does the audio control loop and send the output >> for playback. May be its not required, if we can make a sink block >> with ALSA and implement the audio control loop. >> >> Here, I need your inputs. Can you please state the requirements. How >> it has to be in GNU radio chain etc. >> >> -ben >> >> ------------------------------------------------------------------------ >> *From:* USRP-users <usrp-users-boun...@lists.ettus.com> on behalf of >> Marcus Müller via USRP-users <usrp-us...@lists.ettus.com> >> *Sent:* Tuesday, September 19, 2017 2:10 AM >> *To:* usrp-us...@lists.ettus.com; GNURadio Discussion List >> *Subject:* Re: [USRP-users] Audio Control loop testing >> >> >> Hi Ben, >> >> >> that's the old multi-clock problem we've been talking about multiple >> times – it's hard to even define what the "correct" clock is, so you >> usually just settle on recovering the transmitter clock and, if you >> were doing this in hardware, would derive the audio DAC's clock from >> that. >> >> In a software receiver, you need to estimate the offset of the audio >> DAC clock from the sender's audio clock. That's hard to do properly, >> because these clock offsets might be to fine to do it with general >> purpose PC CPU software. But we've talked about all that before on >> the Discuss-gnuradio list! >> >> >> As a way around that, you might use the same clock to derive the RF >> receiver's sampling clock and the audio DAC's sampling clock. You >> then get a direct relation between RF sampling and audio playback, >> for example "every 1 million RF samples, I need to produce one audio >> sample". Fons and I really tried to explain that in about 20 emails >> on discuss-gnuradio. So, I think we've covered the stage of "any >> suggestions on this would be helpful" pretty well. It is a hard >> problem, and there's a solid chance you can't solve it for all use >> cases in software. There's also a solid chance you might be able to >> solve it for a specific use case, but that would require you to >> become an expert on multi-rate processing and clock matching, and >> frankly, you're not showing much progress at that over last 10 months. >> >> >> Best regards, >> >> Marcus >> >> >> >> On 09/16/2017 05:38 AM, Benny Alexandar via USRP-users wrote: >>> Hi, >>> >>> I want to create an artificial audio drift in transmitter side and >>> test it using my audio control loop in receiver. This is what I'm >>> planning. >>> >>> Take an audio wav file which is sampled at 12 kHz. Re sample it such >>> that the sample rate is now having a drift of 100 ppm, ie with >>> sample frequencies with an error up to 12000*100e-6 is 1.2Hz in case >>> of 12kHz sample frequency. Now transmit this audio file using Gnu >>> radio and USRP. >>> Receiver does the channel decoding and audio decoding. >>> So in this most extreme case the receiver drifts with more than one >>> sample per second, so after an hour it is drifted by 1.2*3600 = 4320 >>> samples >>> >>> If the receiver doesn't have an audio control loop then it will go >>> into under run. By enabling the audio control loop i can check the >>> drift compensation. >>> >>> Any suggestions on this method of testing. >>> >>> -ben >>> >>> >>> _______________________________________________ >>> USRP-users mailing list >>> usrp-us...@lists.ettus.com >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
