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
--
The highest human happiness is not the exploitation of the present but the
preparation of the future.
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
