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
