Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Benny Alexandar]

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

Actually I'm new to this field and learning new things in the past 10 months or 
so. My apologies for repeating things.

I'm still wondering how JACK server  and zita-ajbridge kind of audio 
applications are able to address this issue. Since they are addressing the same 
issues for audio streaming through network, why can't it be reused here ?

-ben

From: Benny Alexandar
Sent: Wednesday, October 4, 2017 10:39 PM
To: Marcus Müller; GNURadio Discussion List
Subject: Re: [USRP-users] Audio Control loop testing

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


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

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Marcus Müller]

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.


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

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Benny Alexandar]

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


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

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Marcus Müller]

Hi Benny,


On 03.10.2017 19:48, Benny Alexandar wrote:
> 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.
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.
>
> 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 .
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.
>
> At the input side USRP decides the input rate, slave the audio to this
> rate.
nd we're stating the original problem again. We don't know any of
these rates relative to any other of these rates.

Best regards,
Marcus


smime.p7s
Description: S/MIME Cryptographic Signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Benny Alexandar]

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 

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Benny Alexandar]

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

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Marcus Müller]

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

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Benny Alexandar]

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

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Marcus Müller]

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

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Benny Alexandar]

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 
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 
 
on behalf of Marcus Müller via USRP-users 

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 

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Marcus Müller]

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


On 09/26/2017 07:26 PM, Benny Alexandar wrote:

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 
*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  on behalf of 
Marcus Müller via USRP-users 

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

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Benny Alexandar]

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 
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 
 
on behalf of Marcus Müller via USRP-users 

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 

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Benny Alexandar]

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 
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 
 
on behalf of Marcus Müller via USRP-users 

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 

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Marcus Müller]

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  on behalf of
> Marcus Müller via USRP-users 
> *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

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Benny Alexandar]

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  on behalf of Marcus 
Müller via USRP-users 
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

Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing

[Marcus Müller]

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