[pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions
tanuk at iki.fi
Wed Apr 24 07:29:03 UTC 2019
On Mon, 2019-04-22 at 11:23 +0200, Georg Chini wrote:
> On 22.04.19 09:34, Tanu Kaskinen wrote:
> > On Sat, 2019-04-20 at 11:38 +0200, Georg Chini wrote:
> > > PA uses malloc() in the IO-thread, so are we doing things wrong?
> > > I think using malloc() when a parameter changes is not interfering
> > > with real-time operation because the filter must be reset after
> > > a parameter change anyway.
> > Where exactly is malloc() used? Sounds like a bug.
> Well, for example pa_memblock_new() potentially uses malloc and
> this is surely used from the I/O thread. I did not check, but I guess
> there are also places where something like pa_xstrdup() or pa_xnew()
> is used from the I/O thread. At least I was not aware that there
> are any restrictions.
> pa_rtpoll_item_new() also potentially uses malloc().
> All in all there are many places where malloc() might be used.
pa_memblock_new() and pa_rtpoll_item_new() both use malloc() only if
they run out of preallocated blocks/items (and the preallocation is
done precisely to avoid calling malloc()).
> > > Well, after evaluation of the feedback I have been getting so far,
> > > I do not think I will make an attempt to create some plugin-sink.
> > > The existing standards do not fit to what I have in mind and
> > > if I read Alexander right they even intentionally do not support
> > > those features.
> > >
> > > Inventing a PA internal standard does not make sense, because
> > > your main argument against implementing the equalizer as a module
> > > was that you did not want to host the DSP code inside PA. If we
> > > did our own standard, new filters would again be bound to PA.
> > New filters would be specific to PA, yes, but not maintained by us, and
> > new filters wouldn't have to go through the review process, so there
> > would still be some benefit in having a PA specific stable plugin API.
> I don't understand. What is the difference between having DSP
> code in a module or in a filter plugin?
The difference is that the module API is not stable, so people can't
maintain their filters outside the upstream PulseAudio repository.
More information about the pulseaudio-discuss