[pulseaudio-discuss] Best place/way to incorporate a convolver into the audio stream

[Tanu Kaskinen]

la, 2009-08-15 kello 06:14 +0100, Neil Wilson kirjoitti:
> Hi,
> 
> I've been spending a bit of time playing with Digital Room Correction
> and I'm trying to work out the best place/way of including the
> convolver filter into the audio stream.
> 
> Obviously I can hack this in and make it work in one situation, but I
> want a more elegant design that will work in a number of scenarios:
> 
> - locally with one sound card.
> - locally with multiple sound outputs (with a different filter
> configuration for each output).
> - filter running locally talking to a dumb device output over the
> network (Apple Airport for example).
> - talking to another pulseaudio soundserver on the network.
> 
> with a view to making this relatively easy to use for the average
> 'consumer'. That suggests Pulseaudio rather than a Jack setup.
> 
> I'm not sure front end solutions (in the media player or Gstreamer)
> are appropriate since it would stop, say, applications like Spotify
> under Wine working properly (incidentally I've packaged Wine with
> PulseAudio drivers for Ubuntu -
> http://www.3spoken.co.uk/2009/08/making-wine-sound-work-with-pulseaudio.html).
> 
> Is there a way with PulseAudio to include the convolver in the audio
> stream or should I be looking at patching the filter in at the ALSA
> layer? Am I looking at this the right way? What would you suggest as
> the best design approach here?
> 
> All suggestions appreciated.

Currently the easiest path would probably be to create a new virtual
sink module similar to module-ladspa-sink (actually you might be able to
use that module as is if there exists a suitable LADSPA filter). Just
recently Jason Newton made an equalizer module using this approach. More
information about that can be read at
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-August/004730.html

That approach is not ideal from design point of view. Such virtual sinks
piggyback on other sinks, which doesn't make much conceptual sense. It
also makes it more difficult to e.g. write a gui that adds effects to
arbitrary sinks.

Last spring I started working on some kind of a "framework" for adding
filters to any sink, source or stream. The status of the work is that it
generally works, but has a known race condition (which has not been
triggered so far, but OTOH it hasn't been used much). The pa_pipeline
implementation should be rewritten - instead of fiddling with atomic
pointers, updating should be done using the pa_aupdate facility.

The git repository is available at
http://gitorious.org/~tanuk/pulseaudio/tanuk-clone (it's the filter
branch). If you look at the pa_filter header (pulsecore/filter.h), you
can see that there are some assumptions about the filters: the filters
should not have any latency and they have to be able to process chunks
of any size. In order to make the framework more useful, the filters
should be able to tell their latency and to declare that they only
accept chunks of certain size. Implementing that, and making it work
correctly with rewinds, seems very non-trivial to me. It's on my todo
list, but it looks like I will have very little time in near future to
work on this. If you took this project forward, I would be very
grateful!

-- 
Tanu Kaskinen