On Mon, Nov 14, 2016 at 04:59:24PM +0000, Benny Alexandar wrote:
> I have some questions regarding it.
> How many blocks of audio the internal buffer need to store ?
Enough to keep feeding samples to the audio HW until the sink's
work() is called again.
> When does the copy from gr buffer to internal buffer happens ? Is it
> during the audio hardware driver call back or during gr scheduling
> the audio sink ?
When gr calls the sink's work().
> Before copying to the internal buffer the audio block has to be played
> to prevent overwrite of data. In a way it has to do the same check
> what the gr buffers do, space is available to copy etc.
The sink's work() will block until all input data is transferred
to the internal buffer.
> Why not handle this with gr buffer ? Audio sink can query the
> available data in its input queue.
I don't understand what exactly you mean. If you mean that the
internal buffer isn't needed and that the gr buffer can take
its role, that's not going to work.
> I was reading the paper "usingdll.pdf" in that the first figure (fig 1)
> ( The thin (blue) line is the exact mapping we want. Note
> that in this example the real sample frequency is
> slightly lower that the nominal — the thin line
> is lagging the grid as time advances.)
> In an ideal case the thin blue line should intersect all the grid points.
> Why the real sample frequency is slightly lower than nominal ?
It's just an example, illustrating what happens in that case.
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)