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