[pulseaudio-discuss] RFC: Filter module loader

[Tanu Kaskinen]

On Fri, 2011-04-15 at 23:21 +0200, Maarten Bosmans wrote:
> Do the developers of those applications feel the same? Perhaps this is
> a right time to step back and think about what we want to achieve. I'd
> say that some sort of client-side access to volume ramping
> (fade-in/fade-out) is appropriate. But effects like equalizer is
> probably better off in a gstreamer pipeline.

Doing effects in Pulseaudio removes the need to implement equalizer
support in each and every music player. With better filter support it
should also be easy to configure per-output eq settings. If the user
uses both speakers and headphones, the same settings very likely aren't
ideal for both outputs. Clients shouldn't care about the current
routing, so this is another reason why Pulseaudio is the right place for
user equalizers.

> I'm sorry for sounding perhaps a bit grumpy, but I am a bit hesitant.
> This is really something that should be planned carefully. PulseAudio
> can't be everything for everybody. That said, it is perfectly possible
> that I miss some important usage scenario's, especially you seem to be
> working on embedded stuff, with other demands on pulse.

Embedded systems (or at least phones) require very flexible filter
setups at the level where Pulseaudio is operating. There are many
filters that need to be dynamically enabled and disabled at runtime.

You may be right in that this sounds like reimplementing gstreamer,
though. At least I have had some ideas about reimplementing the whole
audio processing pipeline (volumes, mixing, resampling, filters) as
abstract elements like in gstreamer... The reason being mostly that then
rewinds could maybe be done in some generic (i.e. understandable) way
instead of the current approach that seems like a mess (on the surface
at least - I haven't *really* tried to grok it).

-- 
Tanu