[pulseaudio-discuss] RFC: Filter module loader
mkbosmans at gmail.com
Fri Apr 15 14:21:55 PDT 2011
2011/4/15 pl bossart <bossart.nospam at gmail.com>:
>> Here is my first draft of a filter module to automatically load
>> equalizer and/or echo-cancel modules if automagically and in a manual
>> but convenient way.
> Thanks for these patches, this is interesting, Arun and I were talking
> last week about better support for effects, after we realized how apps
> such as banshee/rhythmbox handle effects and volume ramps with awful
> hard-coded gstreamer pipelines. All this PCM processing should move to
> PulseAudio really.
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.
> Your approach makes sense with the existing solution based on virtual
> sinks/sources, but with the current implementation, the effects are
> really global, post-mix. If you want to add an effect on a specific
> stream, you need to create a new sink and move the sink-input. That
> really doesn't scale. Ideally we would want to use a linked list of
> effects, so that the effects can be added/enabled/disabled/removed
> quickly and their order modified, and we should be able to handle
That looks awfully lot like a reimplementation of gstreamer. Is that
really what we want?
> - local/per-stream effects.
> - global/post-mix effects
> - aux effects (such as reverb)
I consider the global reverb option one of the most terrible parts of
a lot of windows audio drivers. What's the use case for that?
> We would also need a standard way for apps to set/get the parameters
> needed by effects.
> This isn't new, this is what Android/AudioFlinger/OpenSL ES implement.
> In most cases, users really care about global effects only, but you
> may want to have a specific filter on a stream (ReplayGain or some
> volume ramp for example).
> I also don't think using a 10s timer is really great to check if the
> effect is actually needed. If you had a linked list you wouldn't need
> to do this type of things.
> let me know if I am making any sense, it's been a long week...
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.
More information about the pulseaudio-discuss