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>
