[pulseaudio-discuss] native digital equalizer for pulseaudio submission

[Jason Newton]

I think I'm close to having this guy work stably but despite hacking at
it all day, it's still not.  I tried implementing the algorithm you
discussed on IRC Tanu but there is something still not performing right.
 Oddly enough, things perform better if
module-equalizer-sink.c:398,404-426 are commented out!?  Suggestions?
Any eyes that can spot if I'm not using the memblockq properly?



Attached current patch against git head.

Jason

On 07/18/2009 12:48 PM, Jason Newton wrote:
> 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: module-equalizer.patch.gz
Type: application/x-gzip
Size: 8234 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20090721/ac822e20/attachment.bin>