[pulseaudio-discuss] [PATCH] new virtual-sink and virtual-source modules

Lennart Poettering lennart at poettering.net
Wed Feb 17 07:54:43 PST 2010


On Tue, 16.02.10 22:19, pl bossart (bossart.nospam at gmail.com) wrote:

> 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



More information about the pulseaudio-discuss mailing list