|
The conversion error of clocks should be
negligible compared to audio sample rate as we are dealing with
microseconds timer.
No. I'll stop contributing to this discussion now. The average
sound card has a 25ppm clock accuracy, according to design specs
of Texas Instrument audio ADC/DAC ICs. So, that's way, way better
than your CPU clock, and even more better than your CPU clock
sampled through a system call in a non-realtime userland
application.
I wish you the best with your application! I'm clearly not
helping you, because I feel that you're still repeating things
that I've already tried to explain.
Best regards,
Marcus
On 10/04/2017 07:09 PM, Benny Alexandar
wrote:
>>Yeah. But that doesn't help at all, since clock recovery
of any digital receiver will give you samples resampled to the
transmitter's clock...
>>Anyway, notice how you say "roughly". Now, compare that
"roughness" to the "roughly the same" transmitter and receiver
audio clock.
>>You're at least in the same order of magnitude here, and
my point is that by introducing yet another clock into this
>>(the abyssimal bad PC clock), you're making things way
worse than they need be, and atop of that, unnecessarily
complicated.
Actually there exist a resampler at the input as well. After
clock recovery the base band samples are synchronized with
transmitter. Then the symbols which make the transmission
frames are timestamped. At this point we are in sync with
transmitter.
The conversion error of clocks should be negligible compared
to audio sample rate as we are dealing with
microseconds timer. If you read Fons paper again, you will find
his paper uses *some* clock which can be CPU, or real-time or
any clock.
According to him "The stability of the timer used to get
timestamps on both the input and output streams of the resampler
doesn't matter much,
it basically almost disappears from the equations. Any random
variations will be smoothed by a DLL."
>> Again, I don't see where you see the audio device clock
in your system.
>> I'd be very thankful if you could explain **that** to
me, since well, there's no clock line between my sound card and
my CPU.
One way to make a sound card clock is to use the callback from
JACK or ALSA and count samples.
The code must be robust in the sense that at no time, must even
a single sample be lost.
With JACK this should be possible, and the callback happens
precisely when the number of samples
configured for the buffer is over.
>> aaaand we're stating the original problem again.
>> We don't know any of these rates relative to any other
of these rates.
Now the audio decoded is synchronized to transmitter rate and
send to sound card. By using a resampler this audio clock is
adjusted to sound card clock rate.
-ben
From: Benny
Alexandar
Sent: Tuesday, October 3, 2017 11:18 PM
To: Marcus Müller; GNURadio Discussion List
Subject: Re: [USRP-users] Audio Control loop testing
By using the PC clock, and calling set time now with
the current PC time before scheduling streaming. This will
make the USRP
tick counter roughly match the PC clock.
usrp_source->set_time_now(uhd::time_spec_t(secs, micros,
long(1e6));
Then use the Jack audio
clock and maps this audio
clock to system one .
At the input side USRP decides the input rate, slave the
audio to this rate.
-ben
From:
Benny Alexandar
Sent: Friday, September 29, 2017 11:59 PM
To: Marcus Müller; GNURadio Discussion List
Subject: Re: [USRP-users] Audio Control loop testing
>>
you don't get the sound card clock anywhere in
software. If you did, there would >> be no problem
Jack
uses audio
clock and maps this audio clock to system one
with the use of DLL (delay locked loop).
-ben
From:
Benny Alexandar
Sent: Wednesday, September 27, 2017 10:45 PM
To: Marcus Müller; GNURadio Discussion List
Subject: Re: [USRP-users] Audio Control loop
testing
>>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
|
smime.p7s