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
