[pulseaudio-discuss] RFC: realtime prio for null and tunnel sinks? (Was Re: Why only selected modules try to acquire realtime priority?)

David Henningsson david.henningsson at canonical.com
Wed Jun 22 13:06:39 PDT 2011


On 2011-06-22 15:56, Colin Guthrie wrote:
> 'Twas brillig, and marcin at saepia.net at 20/06/11 17:20 did gyre and gimble:
>> And the next one, for tunnels.
>
> Both seem reasonable, but let me consult with others first.
>
> So guys, should these modules' threads look to be using RT prio?
>
> Col
>

FWIW, I remember Lennart told me something long ago about redesigning 
PulseAudio so that audio packets did not have to pass through non-RT 
threads. E g, if you would have a client which had its output thread RT, 
that would keep the entire chain RT prio (to minimize risk of dropouts 
at all stages), something that's not possible now, at least not with 
protocol-native.

With that in the back of our heads, I'm not sure what problem we solve 
by having null-sink thread(s) running on RT prio?

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic


More information about the pulseaudio-discuss mailing list