[pulseaudio-discuss] native digital equalizer for pulseaudio submission

[Jason Newton]

Tanu Kaskinen wrote:

> > (Line numbers in the following refer to the patch file.)
> >
> > I don't think I have enough time before next week to look into this in
> > more detail and actually try things before giving advice, but here are
> > some hints. At 272 you create a new memblock. I think you should get
> > that block from the filtered audio buffer with pa_memblockq_peek. _peek
> > returns a memchunk, set its length to min(nbytes, chunk->length). Return
> > that chunk.
> >
> > Remove the if check at 267, and instead check before that whether the
> > buffer memblockq is empty. If it is, then you need to fill the buffer.
> > You mentioned in IRC that creating memblocks large enough for the
> > algorithm causes problems with shm. My understanding of pa_memblock_new
> > is that it can create blocks of any size, so I don't quite know what
> > problems you ran into. But too big blocks are allocated with pa_xnew,
> > which isn't desirable in a realtime context like this. I think
> > allocating some blocks beforehand at module initialization time would be
> > appropriate here. For this, use pa_memblock_new_user. Provide a free
> > callback that puts the block back to the reserve from which you take new
> > memblocks when filtering.

Attached is the current patch against git head (module-equalizer.patch)
and a patch against the previous patch (prev.patch).

It turns out that the block you mention is never really called, I'm
mostly leaving it there in case the need for it comes back.  The reason
as to why it's not called is documented above the block now.  I also
increased the shared memory slot size so there's no worries above too
big of memchunks now.

> > When requesting for data for filtering, take a memblock from the reserve
> > (or if none are available, allocate new memory and create a new memblock
> > with pa_memblock_new_user). Then call pa_sink_render_into repeatedly
> > until the jumbo-sized memblock is fully populated. Then run the filter
> > on the memblock and push the memblock to the buffer memblockq. The next
> > step is then what I wrote in my first paragraph.

I couldn't figure out a memblockq into this really other than the
original usage but I am now using pa_sink_render_into with a set chunk
size.  While this does a pretty good job w/ filling to the requested
amount, it doesn't do so for free.  I still have the same drop out
issues though not so many alsaish/rewind messages logged.
Also, even if inefficient, the memblock allocations (all of them) are
accounting for zilch time in comparison to sink render requests it would
seem.

> > I think this approach may cause underruns, because pa_sink_render_into
> > is called relatively seldom, but with big requirements. There may not be
> > enough data available from the clients. You may need to tune this
> > algorithm so that every time sink_input_pop_cb is called, you already
> > fill the next memblock for the filter in advance as much as you can.
> > This way the requests for new data come to the clients in a smoother
> > manner.
> >
> > HTH.
> >
I imagine this isn't going to get any better within your new filter api,
right?  Something in the stack (anywhere from mplayer->alsa) is not
liking the idea of a fixed tad of latency and a not to large extra bit
of buffering.  PA itself seems to support the idea with render_into
though.  Thankfully I believe that all sporadic popping that comes from
the module is completely related these problems... I'd like to think the
dsp logic is and has been working for the last few days and there isn't
some random value getting in the mix somewhere.

Further help would be much appreciated but if there's some hero out
there who can just hurry up and get this lame part working properly, I'd
be much obliged.

Jason

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patches.tgz
Type: application/x-compressed-tar
Size: 10983 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20090718/75486ce7/attachment.bin>