Discussion:
[PATCH] new virtual-sink and virtual-source modules
(too old to reply)
pl bossart
2010-02-11 22:47:03 UTC
Permalink
The patches I am about to post provide two modules that could be of
interest to the PulseAudio community.

module-virtual-sink is a template for the addition of PCM processing.
It's basically based on the LADSPA module, I use it for internal
experiments and will enhance it in the future.

module-virtual-source is something new. This is the continuation of my
earlier work to enable paths that were not possible in PulseAudio.
With module-loopback I enabled a source to be played on a sink. Well,
this virtual-source module is the missing complement. It wasn't
possible until now to mix music with the microphone inputs. Now you
can send data to the 'uplink sink' exposed in this module, and it'll
be mixed with the inputs and provided to apps by a virtual source
element.
For example you could be talking with Skype and sharing your music
with the remote party. Or send beeps/tones/alerts/DTMF/whatever. Or
record a conversation.
In addition, this virtual source can be used to add PCM processing on
the inputs if you don't care for this mixing capability but want to
add EQ, DRC, on a capture path.
I played for some time with the idea of adding such a mixing
capability for all sources, just like we have monitor sources on all
sinks, however you may want to do some processing on the inputs before
mixing, and I preferred to implement this mixing capability as an
optional feature in a separate module.

I did struggle to implement some of the callbacks; this is fairly
hairy PulseAudio stuff, you will see a lot of FIXMEs on the code
handling latency/state/volume changes. Contributions are welcome to
stabilize the code.
One known issue: I added some code to wake-up the source when the
virtual sink become active, but at some point the suspend-on-idle
kicks in and the client gets stuck. I need to find a way to prevent
the source from being suspended in that case, even if no client is
connected to the source.

To enable both modules, just add these lines in default.pa
load-module module-virtual-sink sink_name=vsink
set-default-source vsink
load-module module-virtual-source source_name=vsource uplink_sink=uplink
set-default-source vsource

You can then test all this with pavucontrol and reroute the data
wherever you want. Thanks for your feedback.
Cheers,
- Pierre
Lennart Poettering
2010-02-17 03:17:27 UTC
Permalink
Post by pl bossart
The patches I am about to post provide two modules that could be of
interest to the PulseAudio community.
module-virtual-sink is a template for the addition of PCM processing.
It's basically based on the LADSPA module, I use it for internal
experiments and will enhance it in the future.
This definitely makes sense, especially when we'll eventually get the
filtering logic I have mentioined a couple of times.
Post by pl bossart
To enable both modules, just add these lines in default.pa
load-module module-virtual-sink sink_name=vsink
set-default-source vsink
load-module module-virtual-source source_name=vsource uplink_sink=uplink
set-default-source vsource
I have merged both modules to master now since they look mostly good,
and are not invasive. I'll have a closer look soon and fix what there
is left to fix.

Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
pl bossart
2010-02-17 04:19:40 UTC
Permalink
Post by Lennart Poettering
Post by pl bossart
module-virtual-sink is a template for the addition of PCM processing.
It's basically based on the LADSPA module, I use it for internal
experiments and will enhance it in the future.
This definitely makes sense, especially when we'll eventually get the
filtering logic I have mentioined a couple of times.
Humm, I am not sure I remember having seen anything on this 'filtering
logic'. Would you mind providing a pointer to previous posts?
Post by Lennart Poettering
I have merged both modules to master now since they look mostly good,
and are not invasive. I'll have a closer look soon and fix what there
is left to fix.
Cool. Thanks in advance for your feedback.
What I am now looking at is a way to handle sinks and sources in a
more optimized manner for low-latency speech calls: it doesn't make
any sense power-wise to handle uplink and downlink paths in completely
separate threads with their own timers. You use the same latency
settings,sampling frequencies and channel-map on both paths, relying
on completely independent structures results in 2x wakeups for no good
reason. Plus if you start doing processing you need inter-thread
communication for acoustic enhancements. Maybe we could handle both
threads with the same wake-up events (a single rtpoll?), or combine
sink/source threads. I know no one cares with a 50 Wh battery, things
are different in a handheld....
- Pierre
Lennart Poettering
2010-02-17 15:54:43 UTC
Permalink
Post by pl bossart
What I am now looking at is a way to handle sinks and sources in a
more optimized manner for low-latency speech calls: it doesn't make
any sense power-wise to handle uplink and downlink paths in completely
separate threads with their own timers. You use the same latency
settings,sampling frequencies and channel-map on both paths, relying
on completely independent structures results in 2x wakeups for no good
reason. Plus if you start doing processing you need inter-thread
communication for acoustic enhancements. Maybe we could handle both
threads with the same wake-up events (a single rtpoll?), or combine
sink/source threads. I know no one cares with a 50 Wh battery, things
are different in a handheld....
I presume you are talking of the ALSA sink/source stuff?

At FOSDEM I sat down with a couple of gst folks to discuss how to best
integrate echo cancellation and the like into our stack. And so, the
result of those discussions was basically what you are asking for I guess:

The same way as the OSS module drives both the sink and the source of
the same card from the same IO thread we probably should drive ALSA
sinks and sources of the same card from one single thread as well.

Implementing this most likely is an exercise of copy'n'pasting things
around and renaming a few things, and will a be a bit more complex
than the OSS case since we actually might end up driving more than one
sink and more than one source from the same thread. But beyond that it
should be a relatively easy thing to do.

Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
Loading...