Empathy List Archives

BA

Benny Alexandar

Sat, Sep 16, 2017 3:38 AM

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 12000100e-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.23600 = 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

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

MM

Marcus Müller

Mon, Sep 18, 2017 8:40 PM

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 12000100e-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.23600 = 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-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

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-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

BA

Benny Alexandar

Tue, Sep 19, 2017 5:10 PM

Hi Marcus,

Yes its true I couldn' t make much progress on this. Not able to find time as I have a full time job. If I remember correctly, you mentioned that no-one has implemented audio control loop within GNU Radio. And you were suggesting to write it for ALSA and not with JACK.

May I know why not with JACK ? If I need to make it with JACK, GNU radio should run as a client and output to JACK input port and another client which does the audio control loop and send the output for playback. May be its not required, if we can make a sink block with ALSA and implement the audio control loop.

Here, I need your inputs. Can you please state the requirements. How it has to be in GNU radio chain etc.

-ben

From: USRP-users usrp-users-bounces@lists.ettus.com on behalf of Marcus Müller via USRP-users usrp-users@lists.ettus.com
Sent: Tuesday, September 19, 2017 2:10 AM
To: usrp-users@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 12000100e-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.23600 = 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-users@lists.ettus.com mailto:USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Hi Marcus, Yes its true I couldn' t make much progress on this. Not able to find time as I have a full time job. If I remember correctly, you mentioned that no-one has implemented audio control loop within GNU Radio. And you were suggesting to write it for ALSA and not with JACK. May I know why not with JACK ? If I need to make it with JACK, GNU radio should run as a client and output to JACK input port and another client which does the audio control loop and send the output for playback. May be its not required, if we can make a sink block with ALSA and implement the audio control loop. Here, I need your inputs. Can you please state the requirements. How it has to be in GNU radio chain etc. -ben ________________________________ From: USRP-users <usrp-users-bounces@lists.ettus.com> on behalf of Marcus Müller via USRP-users <usrp-users@lists.ettus.com> Sent: Tuesday, September 19, 2017 2:10 AM To: usrp-users@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-users@lists.ettus.com<mailto:USRP-users@lists.ettus.com> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com