[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