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
<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
|