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?
Best regards,
Marcus
On 09/26/2017 06:20 PM, Benny Alexandar
wrote:
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 <address@hidden>
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
<address@hidden> on
behalf of Marcus Müller via USRP-users
<address@hidden>
Sent: Tuesday, September 19, 2017 2:10 AM
To:
address@hidden; 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
address@hidden
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|