Hi,
I’ve got my custom block producing mono audio at 8KS/s which I am
sending to
an audio_sink(8000, “plughw:0,0”) and have some questions.
First question: what is the range of values that each output sample can
assume before clipping? Since they’re floats I am assuming its -1.0 …
+1.0.
Is that correct?
Second question: for now I am providing audio silence but get a constant
stream of aU events displayed on the console. I am a little bothered by
that
because general_work always produces exactly what its asked for:
int
custom_block_ff::general_work(int nof_output_items, gr_vector_int&
nof_input_items, gr_vector_const_void_star& input_items,
gr_vector_void_star& output_items)
{
// handle inputs
// produce audio (even if silence)
consume(0, nof_input_items[0]);
float *out = reinterpret_cast<float*>(output_items[0]);
fill(out, out + nof_output_items, 0.0);
return nof_output_items;
}
Hi,
I’ve got my custom block producing mono audio at 8KS/s which I am
sending to
an audio_sink(8000, “plughw:0,0”) and have some questions.
First question: what is the range of values that each output sample can
assume before clipping? Since they’re floats I am assuming its -1.0 …
+1.0.
Is that correct?
Second question: for now I am providing audio silence but get a constant
stream of aU events displayed on the console. I am a little bothered by
that
because general_work always produces exactly what its asked for:
int
custom_block_ff::general_work(int nof_output_items, gr_vector_int&
nof_input_items, gr_vector_const_void_star& input_items,
gr_vector_void_star& output_items)
{
// handle inputs
…
// produce audio (silence for the time being)
consume(0, nof_input_items[0]);
float *out = reinterpret_cast<float*>(output_items[0]);
fill(out, out + nof_output_items, 0.0);
return nof_output_items;
}
(and continuing… entering tabs above moved the focus to “send”, a
space
sent the half-complete message. Sigh)
This block consumes its input in a very lumpy manner. A lot of samples
are
read that produce no output. Then a lot of output is produced at once as
the
frame is decoded and the output becomes available. That’s why I have it
producing silence just now… the idea is to smooth the lumpy output and
produce whatever output is required even if that is silence.
void
custom_block_ff::forecast(int nof_output_items, gr_vector_int
&nof_input_items_reqd)
{
const size_t nof_inputs = nof_input_items_reqd.size();
fill(&nof_input_items_reqd[0], &nof_input_items_reqd[nof_inputs],
nof_output_items);
}
So, why the audio underruns? Is there a better forecast implementation
that
will help the scheduler to deal with my “lumpy” output?
Kind regards
Steve
On Tue, Sep 08, 2009 at 08:16:07AM +1000, Steve G. wrote:
Hi,
I’ve got my custom block producing mono audio at 8KS/s which I am sending to
an audio_sink(8000, “plughw:0,0”) and have some questions.
First question: what is the range of values that each output sample can
assume before clipping? Since they’re floats I am assuming its -1.0 … +1.0.
Is that correct?
Yes.
...
// produce audio (silence for the time being)
consume(0, nof_input_items[0]);
float *out = reinterpret_cast<float*>(output_items[0]);
fill(out, out + nof_output_items, 0.0);
return nof_output_items;
}
Is there a rate limiting block upstream of custom_block_ff, such as a
usrp or usrp2?
Eric
Hi Eric,
Thanks for the range information … it seems right but I wanted to be
sure.
Is there a rate limiting block upstream of custom_block_ff, such as a
usrp or usrp2?
There is indeed, either a USRP or a file with a throttle at the
appropriate
rate for the block’s input.
Steve
On Wed, Sep 09, 2009 at 10:41:49AM +1000, Steve G. wrote:
Hi Eric,
Thanks for the range information … it seems right but I wanted to be sure.
Is there a rate limiting block upstream of custom_block_ff, such as a
usrp or usrp2?
There is indeed, either a USRP or a file with a throttle at the appropriate
rate for the block’s input.
You almost never want to use a gr_throttle block. It was primarily
created to test some GUI code.
I suspect that if you remove the gr_throttle that the code will work
fine. In the case of the USRP, you’ve got the “two clock problem”.
That is, there are two clocks in the system (usrp and audio) and they
are not synchronized and are running at different rates.
If you are using portaudio, you might try specifying False for the
third parameter to the audio_source constructor. (I’m not sure what
kind of shape the portaudio source/sink is in.)
Eric
Eric
Just a quick thank you for your help.
I had only a fuzzy idea about how forecast works and your explanation
that
audio_sink is rate-limiting meant it fell into place. I still use
throttle
to limit the input rate from file because (like you) I am using GUI
elements
at several stages in the processing pipeline and with the correct
implementation of forecast() for my custom block everything works just
fine.
No audio under-runs despite the two-clocks as I make my block produce
audio
silence if it has nothing to send.
Keep up the good work
Steve
You almost never want to use a gr_throttle block. It was primarily
created to test some GUI code.
Ah. I use it with a GUI to take samples I’ve captured off air to feed
them
at the same rate the USRP would (post-decimation). The idea is the user
gets to save their ‘recordings’ which they can then ‘replay’ as though
they
were live. Its been quite useful to do that.
I suspect that if you remove the gr_throttle that the code will work
fine. In the case of the USRP, you’ve got the “two clock problem”.
That is, there are two clocks in the system (usrp and audio) and they
are not synchronized and are running at different rates.
I could see how that would lead to occasional aU reports but not the
constant stream I currently have. I shall test with the USRP and see if
I
can remove the throttle (although I suspect it could make things a
little
rapid).
If you are using portaudio, you might try specifying False for the
third parameter to the audio_source constructor. (I’m not sure what
kind of shape the portaudio source/sink is in.)
Portaudio?! Thankfully not.
Many thanks,
Steve